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Abstract —Android is an operating system that has heen used 
in a majority of mobile devices. Each application in Android 
runs in an instance of the Dalvik virtual machine, which is 
a register-hased vlrtnal machine (VM). Most applications for 
Android are developed using Java, compiled to Java hytecode 
and then translated to DEX hytecode using the dx tool in 
the Android SDK. In this work, we aim to develop a type- 
based method for certifying non-interference properties of DEX 
bytecode, following a methodology that has been developed for 
Java bytecode certification by Barthe et al. To this end, we develop 
a formal operational semantics of the Dalvik VM, a type system 
for DEX bytecode, and prove the soundness of the type system 
with respect to a notion of non-interference. We then stndy 
the translation process from Java bytecode to DEX bytecode, 
as implemented in the dx tool in the Android SDK. We show 
that an abstracted version of the translation from Java bytecode 
to DEX bytecode preserves the non-interference property. More 
precisely, we show that if the Java bytecode is typable in Barthe 
et al’s type system (which guarantees non-interference) then its 
translation is typable in our type system. This result opens up 
the possibility to leverage existing bytecode verifiers for Java to 
certify non-interference properties of Android bytecode. 

I. Introduction 

Android is an operating system that has been used in many 
mobile devices. According to m, Android has the largest 
market share for mobile devices, making it an attractive target 
for malwares, so verihcation of the security properties of 
Android apps is crucial. To install an application, users can 
download applications from Google Play or third-party app 
stores in the form of an Android Application Package (APK). 
Each of these applications runs in an instance of a Dalvik 
virtual machine (VM) on top of the Linux operating system. 
Contained in each of these APKs is a DEX hie containing 
specihc instructions m to be executed by the Dalvik VM, 
so from here on we will refer to these bytecode instructions 
as DEX instructions. The Dalvik VM is a register-based VM, 
unlike the Java Virtual Machine (JVM) which is a stack-based 
VM. Dalvik is now superseded by a new runtime framework 
called ART, but this does not affect our analysis since both 
Dalvik and ART use the same DEX instructions. 

We aim at providing a framework for constructing trust¬ 
worthy apps, where developers of apps can provide guarantees 
that the (sensitive) information the apps use is not leaked 
outside the device without the user’s consent. The framework 
should also provide a mean for the end user to verify that apps 
constructed using the framework adhere to their advertised 
security policies. This is, of course, not a new concept, and it is 
essentially a rehash of the (foundational) proof carrying code 
(PCC) fj), m, applied to the Android setting. We follow a 


type-based approach for restricting information flow Q in An¬ 
droid apps. Semantically, information flow properties of apps 
are specified via a notion of non-interference il- In this set¬ 
ting, typeable programs are guaranteed to be non-interferrent, 
with respect to a given policy, and typing derivations serve as 
certificates of non-interference. Our eventual goal is to produce 
a compiler tool chain that can help developers to develop 
Android applications that complies with a given policy, and 
automate the process of generating the final non-interference 
certificates for DEX bytecode. 

An Android application is typically written in Java and 
compiled to Java classes (JVM bytecode). Then using tools 
provided in the Android Software Development Kit (SDK), 
these Java classes are further compiled into an Android ap¬ 
plication in the form of an APK. One important tool in this 
compilation chain is the dx tool, which will aggregate the Java 
classes and produce a DEX file to be bundled together with 
other resource files in the APK. Non-interference type systems 
exist for Java source code Q, JVM 10 and (abstracted) DEX 
bytecode without exception handling mechanism E). To build 
a framework that allows end-to-end certificate production, one 
needs to study certificate translation between these different 
type systems. The connection between Java and JVM type 
systems for non-interference has been studied in mol . In 
this work, we All the gap by showing that the connection 
between JVM and DEX type systems. Our contributions are 
the following: 

• We give a formal account of the compilation process 
from JVM bytecode to DEX bytecode as implemented 
in the official dx tool in Android SDK. Section 
details some of the translation processes. 

• We provide a proof that the translation from JVM 
to DEX preserves typeability. That is, JVM pro¬ 
grams typeable in the non-interference type system 
for JVM translates into typeable programs in the non¬ 
interference type system for DEX. 

The development of the operational semantics and the 
type systems for DEX bytecode follows closely the frame¬ 
work set up in 0. Although Dalvik is a registered-based 
machine and JVM is a stack-based machine, the translation 
from one instruction set to the other is for most part quite 
straightforward. The adaptation of the type system for JVM 
to its DEX counterpart is complicated slightly by the need 
to simulate JVM stacks in DEX registered-based instructions. 
The non-trivial parts are when we want to capture both direct 
(via operand stacks) and indirect information flow (e.g., those 
resulting from branching on high value). In 0, to deal with 


both direct and indirect flow, several techniques are used, 
among others, the introduction of operand stack types (each 
stack element carries a type which is a security label), a notion 
of safe control dependence region (CDR), which keeps track of 
the regions of the bytecode executing under a ’high’ security 
level, and the notion of security environment, which attaches 
security levels to points in programs. Since Dalvik is a register- 
based machine, when translating from JVM to DEX, the dx 
tool simulates the operand stack using DEX registers. As the 
type system for JVM is parameterised by a safe CDR and a 
security environment, we also need to define how these are 
affected by the translation, e.g., whether one can construct a 
safe CDR for DEX given a safe CDR for JVM. This was 
complicated by the fact that the translation by dx in general is 
organized along blocks of sequential (non-branching) codes, 
so one needs to relate blocks of codes in the image of the 
translation back to the original codes (see Section 0 . 

The rest of the paper is organized as follows ; in the 
next section we describe some work done for Java bytecode 
security and the work on static analysis for Android bytecode. 
This is important as what we are doing is bridging the 
relationship between these two security measures. Then we 
review the work of Barthe et.al. on a non-interferent type 
system for JVM bytecode. In the remainder of the paper we 
will describe our work, namely providing the type system for 
DEX and proving the translation of typability. We also give 
examples to demonstrate how our methodology is able to detect 
interference by failure of typability. Before concluding, we 
provide our design of implementation for the proof of concept. 

II. Related Work 

As we already mentioned, our work is heavily influenced 
by the work of Barthe et. al. im, a on enforcing non¬ 
interference via type systems. We discuss other related work 
in the following. 

The cloest to our work is the Cassandra project 13, m, 
that aims at developing certified app stores, where apps can 
be certified, using an information-flow type system similar to 
ours, for absence of specific information flow. Specifically, 
the authors of 0, m have developed an abstract Dalvik 
language (ADL), similar to Dalvik bytecode, and a type system 
for enforcing non-interference properties for ADL. Our type 
system for Dalvik has many similarities with that of Cassandra, 
but one main difference is that we consider a larger fragment 
of Dalvik, which includes exception handling, something that 
is not present in Cassandra. We choose to deal directly with 
Dalvik rather than ADL since we aim to eventually integrate 
our certificate compilation into existing compiler tool chains 
for Android apps, without having to modify those tool chains. 

Bian et. al. ifTJIl targets the JVM bytecode to check whether 
a program has the non-interference property. Differently from 
Barthe et. al. their approach uses the idea of the compilation 
technique where they analyse a variable in the bytecode for its 
definition and usage. Using this dependence analysis, their tool 
can detect whether a program leaks confidential information. 
This is an interesting technique in itself and it is possible to 
adopt their approach to analyze DEX bytecode. Nevertheless, 
we are more interested in the transferability of properties 
instead of the technique in itself, i.e., if we were to use their 


approach instead of a type system, the question we are trying to 
answer would become “if the JVM bytecode is non-interferent 
according to their approach, is the compiled DEX bytecode 
also non-interferent?”. 

In the case of preservation of properties itself the idea 
that a non-optimizing compiler preserves a property is not 
something new. The work by Barthe et. al. El shows that with 
a non-optimizing compiler, the proof obligation from a source 
language to a simple stack based language will be the same, 
thus allowing the reuse of the proof for the proof obligation in 
the source language. In showing the preservation of a property, 
they introduce the source imperative language and target 
language for a stack-based abstract machine. This is the main 
difference with our work where we are analyzing the actual 
dx tool from Android which compiles the bytecode language 
for stack-based virtual machine (JVM bytecode) to the actual 
language for register-based machine (DEX bytecode). There 
are also works that address this non-interference preservation 
from Java source code to JVM bytecode M. Our work can 
then be seen as a complement to their work in that we are 
extending the type preservation to include the compilation from 
JVM bytecode to DEX bytecode. 

To deal with information flow properties in Android, there 
are several works addressing the problem m, Qsi, m, 
El, El, El, E3, El, El, lEl although some of them 
are geared towards the privilege escalation problem. These 
works base their context of Android security studied in El- 
The tool in the study, which is called Kirin, is also of 
great interest for us since they deal with the certification of 
Android applications. Kirin is a lightweight tool which certifies 
an Android application at install time based on permissions 
requested. Some of these works are similar to ours in a sense 
working on static analysis for Android. The closest one to 
mention is ScanDroid m, with the underlying type system 
and static analysis tool for security specification in Android 
El- Then along the line of type system there is also work 
by Bugliesi et. al. called Lintent that tries to address non¬ 
interference on the source code level El- The main difference 
with what we do lies in that the analysis itself is relying on the 
existence of the source (the JVM bytecode for ScanDroid and 
Java source code for Lintent) from which the DEX program 
is translated. 

There are some other static analysis tools for Android 
which do not stem from the idea of type system, e.g. Trust- 
Droid El and ScanDal El- TrustDroid is another static 
analysis tool on Android bytecode, trying to prevent infor¬ 
mation leaking. TrustDroid is more interested in doing taint 
analysis on the program, although different from TaintDroid 
El in that TrustDroid is doing taint analysis statically from 
decompiled DEX bytecode whereas TaintDroid is enforcing 
run time taint analysis. ScanDal is also a static analysis for 
Android applications targetting the DEX instructions directly, 
aggregating the instructions in a language they call Dalvik 
Core. They enumerate all possible states and note when 
any value from any predefined information source is flowing 
through a predefined information sink. Their work assumed 
that predefined sources and sinks are given, whereas we are 
more interested in a flexible policy to define them. 

Since the property that we are interested in is non¬ 
interference, it is also worth mentioning Sorbet, a run time 


binop op 

binary operation on stack 

push c 

push value on top of a stack 

pop 

pop value from top of a stack 

swap 

swap top two operand stack values 

load X 

load value of x on stack 

store X 

store top of stack in variable x 

ifeq j 

conditional jump 

goto j 

unconditional jump 

return 

return the top value of the stack 

new C 

create new object in the heap 

getfield / 

load value of held /on stack 

putfield / 

store top of stack in held / 

newarray t 

create new array of type t in the heap 

arraylength 

get the length of an array 

arrayload 

load value from an array 

arraystore 

store value in array 

invoke toid 

Invoke method indicated by mjD 


with arguments on top of the stack 

throw 

Throw exception at the top of a stack 

where op € {+, - 

, X,/}, c € e A, j 6 PP, C eC, 

f € P,t andmiDsAl. 


Fig. 1; JVM Instruction List 


enforcement of the property by modifying the Android oper¬ 
ating system QSl, Go). Their approach is different from our 
ultimate goal which motivates this work in that we are aiming 
for no modihcation in the Android operating system. 

III. Type System for JVM 

In this section, we give an overview of Barthe et. al’s type 
system for JVM. Due to space constraints, some details are 
omitted and the reader is referred to El for a more detailed 
explanation and intuitions behind the design of the type system. 
Readers who are already familiar with the work of Barthe et. 
al may skip this section. 

A program P is given by its list of instructions given 
in Figure The set X is the set of local variables, V = 
'lyj C{J{null} is the set of values, where C is an (inhnite) 
set of locations and null denotes the null pointer, and W is 
the set of program points. We use the notation * to mean that 
for any set X, X* is a stack of elements of X. Programs are 
also implicitly parameterized by a set C of class names, a set 
T of held identihers, a set M. of method names, and a set of 
Java types 7j- The instructions listing can be seen in Figure [T] 

Operational Semantics The operational semantics is given 
as a relation State x (State + (V,heap)) where m 

indicates the method under which the relation is considered 
and T indicates whether the instruction is executing normally 
(indicated by Norm) or throwing an exception, (sometimes 
we omit m whenever it is clear which m we are referring 
to, we may also remove t when it is clear from the context 
whether the instruction is executing normally or not ). State 
here represents a set of JVM states, which is a tuple (i, p, os, h) 
where i e W is the program counter that points to the next 


instruction to be executed; p € A" ^ V is a partial function 
from local variables to values, os e V* is an operand stack, 
and h 6 heap is the heap for that particular state. Heaps are 
modeled as partial functions h.: C O + A, where the set O 
of objects is modeled as C x (JF V), i.e. each object o € O 
possess a class class(o) and a partial function to access held 
values, which is denoted by o.f to access the value of held / of 
object o. A is the set of arrays modeled as N x (N ^ V) x W 
i.e. each array has a length, partial function from index to 
value, and a creation point. The creation point will be used to 
dehne the notion of array indistinguishability. Heap is the set 
of heaps. 

The program also comes equipped with a partial function 
Handlerm : W x C ^ W. We write HandlermC*, C) = t 
for an exception of class C & C thrown at program point i, 
which will be caught by a handler with its starting program 
point t. In the case where the exception is uncaught, we write 
Handlerm(i, C) t instead. The hnal states will be (V + >C) x 
Heap to differentiate between normal termination {v, h) 6 
V X Heap, and an uncaught exception {{l),h) e £ + Heap 
which contains the location I for the exception in the heap h. 

op denotes here the standard interpretation of arithmetic 
operation of op in the domain of values V (although there is 
no arithmetic operation on locations). 

The instruction that may throw an exception primar¬ 
ily are method invocation and the object/array manipula¬ 
tion instructions, {np} is used as the class for null pointer 
exceptions, with the associated exception handler being 
RuntimeExceptionHandling. The transitions are also 
parameterized by a tag r 6 {Norm} + C to describe whether 
the transition occurs normally or some exception is thrown. 

Some last remarks: hrstly, because of method invocation, 
the operational semantics will also be mixed with a big step 
semantics style from method invocations of method m 
and its associated result, to be more precise is a transitive 
closure of Then, for instructions that may not throw 
an exception, we remove the subscript {TO,Norm} from 
because it is clear that they have no exception throwing op¬ 
erational semantic counterpart. A list of operational semantics 
are contained in Figure We do not show the full list of 
operational semantics due to space limitations. However, the 
interested reader can see Figure in Appendix for the full 
list of JVM operational semantics. 

Successor Relation The successor relation VP x PP 
of a program P are tagged with whether the execution is 
normal or throwing an exception. According to the types of 
instructions at program point i, there are several possibilities: 

• Pm [*] = goto t. The successor relation is i i-!,Norm ^ 

• F’m[*] = ifoq t- In this case, there are 2 successor 

relations denoted by i i + \ and i t. 

• Fm[*] = return. In this case it is a return point 
denoted by i 

• Pm [*] is an instruction throwing a null pointer excep¬ 
tion, and there is a handler for it (Handler(£ np) = 
t). In this case, the successor is t denoted by i t. 





Pm [t] = push n 

Pjn [*] = pop Pm [t] = return Pm [f] = goto j 

{i, p,os){i + 1, p,n " os) (i,P,v 

Pm[i\ = store x x e dom(p) 

" os) ^ {i + 1, p,os) {i,p,v"os) 

Pm[i] = load X 

'-rv,h (i,p,os) '-r (j,p,os) 

Pm [t] = binop op 712 op ni = n 

{i, p, V :: os) {i + 1, p ® {x f}j os) 

{i,p,os) {i+l,p,p{x) :: os) 

{i, p, rii :: n 2 os) (i + 1, p, n :: os) 

Pm[i\ = swap 

Pm [t] = ifeq j n + f) 

Pm[i] = ifeq j n = 0 

{i, p, vi :: V 2 ■■ os) '-r (i -b 1, p,V 2 ■■ Vi : 

'■os) {i, p,nos){i + 1, p,os) 

{i,p,n:: os) (j,p,os) 


Fig. 2: JVM Operational Semantic (Selected) 


• Pm [*] is an instruction throwing a null pointer excep¬ 
tion, and there is no handler for it (Handler(i, np) t 
). In this case it is a return point denoted by i 

• Pm[i] = throw, throwing an exception C 6 

classAnalysis(m, i), and Handler(i, C) = t. The 
successor relation is i t. 

• Pm[i] = throw, throwing an exception C e 

classAnalysis(m, i), and Handler(i, C) = t. It is 
a return point and the successor relation is i 

• Pm[i] = invoke toid, throwing an exception C 6 

excAnalysis(miD), and Handler(i, C) = t. The 
successor relation is i t. 

• Pm[i] = invoke toid, throwing an exception C e 
excAnalysis(miD), and Handler(i,C) f. It is a 
return point and the successor relation is i 

• Pm[i] is any other cases. The successor is its imme¬ 
diate instruction denoted by i ^ + l 

Typing Rules The security level is defined as a partially 
ordered set (S,<) of security levels S that form a lattice, u 
denotes the lub of two security levels, and for every k e S, 
liftk is a point-wise extension to stack types of Xl.k u 1. The 
policy of a method is also defined relative to a security level 
kobs which denotes the capability of an observer to observe 
values from local variables, fields, and return values whose 
security level are below /cobs-The typing rules are defined in 
terms of stack types, that is a stack that associates a value 
in the operand stack to the set of security levels S. The stack 
type itself takes the form of a stack with corresponding indices 
from the operand stack, as shown below. 

Operand Stack Security Stack 

Top -► os[0] ► 

os[l] ◄-► 

os [2] I -► 


st[0] 

st[l] 


st[2] 


Same size as 
Operand stack 


We assume that a method comes with its security policy of 

the form ka kr where ka represents a list {vi ■■ ki,... ,Vn '■ 
kn} with ki e S being the security level of local variables 


Vi 6 TZ, kfi is the effect of the method on the heap and kr 
is the return signature, i.e. the security levels of the return 
value. The return signature is of the form of a list to cater for 
the possibility of an uncaught exception on top of the normal 
return value. The kr is a list of the form {Norm ; fc„,ei : 
/Cei,. • •, e„ : ke^ } where is the security level for the normal 
return value, and is the class of the uncaught exception 
thrown by the method and fee. is the associated security level. 
In the sequel, we write kr[n] to stand for kn and kr[ei\ to 
stand for feg.. An example of this policy can be {1 : L,2 ; 

H} ^ {Norm ; L} where L,H e S,L < kobs, H ^ kobs which 
indicates that the method will return a low value, and that 
throughout the execution of the method, the security level of 
local variable 1 will be low while the security level of local 
variable 2 will be high. 

Arrays have an extended security level than that of the 
usual object or value to cater for the security level of the 
contents. The security level of an array will be of the form 
k\kc\ where k represents the security level of an array and 
kc will represent the security level of its content (this implies 
that all array elements have the same security level kc)- Denote 
^ext j-jjg extension of security levels S to define the array’s 
security level. The partial order on S will also be extended 
with : 

k<k' k,k'eS k<k' k,k'eS 6 5'=’^* 

k[kc] k'[kc] 

Generally, in the case of a comparison between extended 
level k[kc] e 5®’^* and a standard level k' 6 S, we only 
compare k and k' w.r.t. the partial order on S. In the case 
of comparison with kobs, since kobs e 5 an extended security 
k[kc] is considered low (written k[kc] < kobs) if k < kobs- 
Only fcobs and se (defined later) will stay in the form of S, 
everything else will be extended to also include the extended 
level 5®’'*. 

The transfer rules come equipped with a security policy for 
fields ft: JF ^ 5®’^* and at: W 5®’^* that maps the creation 
point of an array with the security level of its content. at(o) 
will also be used to denote the security level of the content of 
array a at its creation point. 

The notation F is used to define the table of method 
signatures which will associate a method identifier mm and 
a security level k e S (of the object invoked) to a security 






Pm[z] = load a; P[i]m = 

store X 

se(i) u k < ka(x) 

Pm[i] = swap 

se,i 1- sf =► {ky{x) u se(z)) :: st 

se,i\- k 

:: st => st it- ki 

: k2 st => k2 ki :: st 

P[i]m = ifeq j Vj' e region(z. Norm), k 

< se{j') 

Pm[i] = goto j 

Pm [*] = push n 

region, se,i\- k :: st ^ liftk(sf) 


it- st ^ st 

it- st ^ se(i) :: st 

P[i]m = binop op 

Pm[i] = 

return se{i) uk < kr\n^ 

Pm [*] = pop 

se, it- ki :: ^2 :: st => {ki U A:2 U se(i)) :: st 

ka 

kr,se,i t- k :: st ^ 

it- k:: st => st 


Fig. 3: JVM Transfer Rule (Selected) 


signature The collection of security signatures of a 

method m is defined as Policiesr(miD) = I k e S}. 

A method is also parameterized by a control dependence 
region (CDR) which is defined in terms of two functions: 
region and jun. The function region : W piVV) can 
be seen as all the program points executing under the guard of 
the instruction at the specihed program point, i.e. in the case 
of region(i) the guard will be program point i. The function 
jun(z) itself can be seen as the nearest program point which 
all instructions in region(z) have to execute (junction point). 
A CDR is safe if it satishes the following SOAP (Safe Over 
Approximation) properties. 

Definition III.l. A CDR structure (region, jun) satisfies the 
SOAP properties if the following properties hold : 

SOAPl. 6 VV and tag t such that i j and i k 

and j + k (i is hence a branching point), k € 
region(i,r) or k = jun(i,r). 

SOAP2. \/i,j,k € VV and tag t, if j 6 region(j,T) 
and j !->• k, then either k e region(i,r) or 
A: = jun(i,r). 

SOAP3. Vi,j € VV and tag t, if j e region(i,T) and j 
is a return point then jun(i,r) is undefined. 

SOAP4. Vi € VV and tags ti,T 2 if jun(z,Ti) and 
jun(i,r 2 ) are defined and jun{i,Ti) jun(i,T 2 ) 
then jun(i,Ti) € region(i,r 2 ) or jun(i,T 2 ) e 
region(i,ri). 

SOAPS. Vi,j € VV and tag t, if j € region(i,T) and 
j is a return point then for all tags t' such that 
jun(i,r') is defined, jun(i,T') € region(i,T). 

SOAP6. Vi € VV and tag ti, if i then for all 
tags r 2 , region (i,r 2 ) £ region(i,Ti) and if 
jun(i,r 2 ) is defined, jun(i,r 2 ) € region(i, ri). 

The security environment function se : VV ^ 5 is a map 
from a program point to a security level. The notation ^ 
represents a relation between the stack type before execution 
and the stack type after execution of an instruction. 

The typing system is formally parameterized by : 

F: a table of method signatures, needed to dehne the 

transfer rules for method invocation; 

ft: a map from helds to their global policy level; 

CDR: a structure consists of (region, jun). 


se: security environment 

sgn: method signature of the current method 

thus the complete form of a judgement parameterized by a tag 
r e {Norm + C} is 

F, ft, region, se, sgn, Si ^ st 

although in the case where some elements are unnecessary, we 
may omit some of the parameters e.g. i t- Si ^ st 

As in the operational semantics, wherever it is clear that 
the instructions may not throw an exception, we remove the 
tag Norm to reduce clutter. The transfer rules are contained 
in Figure |^(for the full list of transfer rules, see Figure in 
AppendixjQ. Using these transfer rules, we can then dehne 
the notion of typability: 

Definition III.2 (Typable method). A method m is typable 
w.r.t. a method signature table F, a global field policy ft, a 
policy sgn, and a CDR regioUm : VV piVV) if there 
exists a security environment se : VV S and a function 
S : VV iS* s.t. Si = e and for all i,j € VV, and exception 
tags e e (Norm + C}: 

(a) i j implies there exists st 6 S* such that 
F, ft, region, se, sgn, i Si => st and st E Sj; 

(b) i implies F, ft, region, se, sgn, Si ^ 

where E denotes the point-wise partial order on type stack 
w.r.t. the partial order taken on security levels. 

The Non-interference dehnition relies on the notion of 
indistinguishability. Loosely speaking, a method is non- 
interferent whenever given indistinguishable inputs, it yields 
indistinguishable outputs. To cater for this dehnition, hrst there 
are dehnitions of indistinguishability. 

To dehne the notions of location, object, and array indis¬ 
tinguishability itself Barthe et. al. dehne the notion of a /3 
mapping. /3 is a bijection on (a partial set of ) locations in the 
heap. The bijection maps low objects (objects whose references 
might be stored in low helds or variables) allocated in the 
heap of the hrst state to low objects allocated in the heap of 
the second state. The object might be indistiguishable, even if 
their locations are different during execution. 












Definition III.3 (Value indistinguishability). Letting v,vi,V 2 e 
V, and given a partial function f3 e C ^ C, the relation 
V X V defined by the clauses : 


null 


null 


V eff 

v^pv 


Vl,V2^C /3(ui)=U2 
Vi V 2 


Definition III.4 (Local variables indistinguisbability). For 

p, p' : X V, we have P k p P' P P' 

same domain and p{x) p'{x) for all x e dom(p) such that 

^a(^) — ^obs- 


Definition III.5 (Object indistinguisbability). Two objects 
Oi, 02 6 O are indistinguishable with respect to a partial 
function (j e C ^ C (noted by oi ^ 2 ) if and only if 

Oi and 02 are objects of the same class and Oi.f ~p 02 -f for 
all fields f 6 dom(oi) s.t. ft(/) < kohs- 


Definition III.6 (Array indistinguishability). Two arrays 
01,02 € A are indistinguishable w.r.t. an attacker level fcobs 
and a partial function j3 € C C (noted by oi ^ 2 ) 

if and only if oi.length = 02.length and, moreover, if 
at(oi) < fcobs. then Oi[i] '^p 02(1] for all i such that 
0 < i < oi-length. 


Definition III.7 (Heap indistinguishability). Two heaps hi and 
/i 2 are indistinguishable, written hi ~k„i,„,p ^ 2 . with respect to 
an attacker level ko^gand a partial function fi e C ^ C iff: 


• (3 is a bijection between dom(/3) and rng(/3); 

• dom(/3) £ dom(/ii) and rng(,8) £ dom(fc 2 ),' 


drop fcobs and write oi 02 if fcobsis obvious. We may also 

- kh - - 

drop fc/j from a policy fc^ ->• kr and write fc^ ^ k^ if k^ is 
iiTelevant to the discussion. 

Definition III.9 (Non -interferent JVM method). A method m 
is non-interferent w.r.f. a policy ka ->■ kr, if for every attacker 
level fcobs. every partial function fi € C C and every pi, P 2 £ 
X -^V,hi, /i 2 ) h'i,h 2 6 Heap, ri, r 2 e V + £ s.t. 

(l,pi,e,/ii) hi'-k„^,,ph 2 
(l,P2,e,fc2) r2,/i2 Pi -k„i,B,kf,p P^ 

there exists a partial function fi' e C ^ C s.t. fi £ fi' and 
(fi^h'i) -k„^„,p',kf { 1 ^ 2 ,h' 2 ) 


Because of method invocation, there will be a notion of a 
side effect preorder for the notion of safety. 

Definition III.IO (Side effect preorder). Two heaps fci, ^2 e 
Heap are side effect preordered (written as hi <k ^2) with 
respect to a security level k € S if and only if dom(fci) £ 
dom(fc 2 ) and hi{l).f = h 2 {l).f for all location I 6 dom(/ii) 
and all fields / e .F such that k ^ ft(/). 

From which we can define a side-effect-safe method. 

Definition III.ll (Side effect safe). A method m is side-effect- 
safe with respect to a security level kh if for all local variables 
X e dom(p), p € X V, all heaps h, h' € Heap and value 
V 6 V, (1, p, e, fc) V, h' implies h <k^ h'. 


• 'He dom(/?),/ii(() ~fcob,./3 fc2(/3(0) where hffl) 
and /i2(/3(0) ^ire either two objects or two arrays. 

Definition III.8 (Output indistinguishability). Given an at¬ 
tacker level fcobs. a partial function j3 e C ^ C, an output 
level kr, the indistinguishability of two final states in method 
m is defined by the clauses : 

hi ~fcobB,/3 ^2 kr[n] < fcobs ^ Vi V2 

-fcobs,/ 3 .fc. (^2,^2) 

hi '^fcobs,/3 ^2 (class( fci (/i) ) . fc) € kr k ^ fcobs ^p ^2 


hi 

{{h),hi) '-h„bs,P,kr W2.),h2) 

~fcobs./3 h 2 (class(fci(£)) :k)ekr 

k ^ /i^obs 

hi 

{{h),hi) -fe^bB./S.fcT (^ 2 ,^ 2 ) 
-fcobs,/3 ^2 {class{h2{l2)) ■■ k) e kr 

k ^ ^obs 


{Vi,hi) '-h„t,,,P,kr ((^2),fc2) 

-'fcobs,/? ^2 (class(fci(;i)) : fci) 6 Av 

ki ^ kohs 


(class(/l 2 (^ 2 )) : fc 2 ) 6 fcr fc 2 ^ fcobs 


((^l>>^l)~fcobs./5.fc;((^2),fc2) 


where ->• indicates logical implication. 

At this point it is worth mentioning that whenever it is 
clear from the usage, we may drop some subscript from 
the indistinguishability relation, e.g. for two indistinguishable 
objects oi and 02 w.r.t. a partial function (3 e C ^ C and 
observer level fcobs. instead of writing oi ^/cobs.P 02 we may 


Definition 111.12 (Safe JVM method). A method m is safe 

w.r.t. a policy ka kr if m is side-effect safe w.r.t. kh and m 
is non-interferent w.r.t. ka kr. 

Definition III.13 (Safe JVM program). A program is safe w.r.f. 
a table F of method signature if every method m is safe w.r.t. 
all policies in Policiesr(TO). 

Theorem III.l. Let P be a JVM typable program w.r.t. safe 
CDRs (region^, junm) and a table F of method signatures. 
Then P is safe w.r.t. F. 

IV. DEX Type System 

A program P is given by its list of instructions in Figure 
The set TZ is the set of DEX virtual registers, V is the set of 
values, and PP is the set of program points. Since the DEX 
translation involves simulation of the JVM which uses a stack, 
we will also distinguish the registers : 

• registers used to store the local variables, 

• registers used to store parameters, 

• and registers used to simulate the stack. 

In practice, there is no difference between registers used to 
simulate the stack and those that are used to store local 
variables. The translation of a JVM method refers to code 
which assumes that the parameters are already copied to the 
local variables. 

As in the case for JVM, we assume that the program comes 
equipped with the set of class names C and the set of fields 
T. The program will also be extended with array manipulation 









Pm[*] = const(r, u) r e dom(p) 

P[i]m = iieq{r,j) p{r) = 0 

Pm[z] = ifeq(r,f) p{r) * 0 

{i,p,h) {i + 1, p® {r v},h) 

{i,p,h) {t,p,h) 

{i,p,h) {i + l,p,h) 

P[f\m = return(rs) 6 dom(p) 

P^[z] = move(r, Tg) r 6 dom(p) 

PnAf] = goto(f) 

(i,p,h) '-r p{rs),h 

{i,p,h) '-r {i + l,p®{r>^ p{rs)},h) 

{i,p,h) {t,p,h) 

Pm[i] = hinop{op,r,ra,rb) r,ra, r;, 6 dom(p) n = p{ra 

) op p{rb) 

{i,p,h) {i + 1, p® {r 1 -^ n},h) 


Fig. 5; DEX Operational Semantic (Selected) 


binop op 

r, raTb 

P(f) = p{ra)op p{rb). 

const 

r, V 

p{r) = V 

move 

r, rs 

II 

'IT 

ifeq 

r,t 

conditional jump if p{r) = 0 

ifneq 

r,t 

conditional jump if sp{r) + 0 

goto 

t 

unconditional jump 

return 

Ts 

return the value of p(rg) 

new 

r, c 

p{r) = new object of class c 

iget 

A roj 

p{r) = p{ro).f 

iput 

rsToJ 

p{ro)-f = p{r) 

newarray 

r, Ti,t 

r = new array of type t with r; 
number of elements 

arraylength 

r, ra 

p{r) = p{r a). length 

aput 

rsTaTi 

Pira)[p{n)] = p{rs) 

invoke 

n, m^p 

invoke p(p[0]).m with n 
arguments stored in p 

moveresult 

r 

store invoke’s result to r. Must 
be placed directly after invoke 

throw 

r 

throw the exception in r 

move- 

r 

store exception in r. Have to 

exception 


be the first in the handler. 

where op e 

-,x,/},z;e 

Z, {r, ra, rb, r*} e 7?., f e VV, 

ceC, f e T and p-.TZ^Z 



Fig. 4; DEX Instruction List 


instructions, and the program will come parameterized by the 
set of available DEX types Td analogous to Java type 7j. The 
DEX language also deals with method invocation. As for JVM, 
DEX programs will also come with a set m of method names. 
The method name and signatures themselves are represented 
explicitly in the DEX file, as such the lookup function required 
will be different from the JVM counterpart in that we do not 
need the class argument, thus in the sequel we will remove 
this lookup function and overload that method ID to refer to 
the code as well. DEX uses two special registers. We will 
use ret for the first one which can hold the return value 
of a method invocation. In the case of a moveresult, the 
instruction behaves like a move instruction with the special 
register ret as the source register. The second special register 
is ex which stores an exception thrown for the next instruction. 


Figure 1^ contains the list of DEX instructions. 

Operational Semantics A state in DEX is just {i,p,h) 
where the p here is a mapping from registers to values and h is 
the heap. As for the JVM in handling the method invocation, 
operational semantics are also extended to have a big step 
semantics for the method invoked. Figure]^ shows some of the 
operational semantics for DEX instructions. Refer to Figure 
in Appendix [D| for a full list of DEX operational semantics. 

The successor relation closely resembles that of the JVM, 
instructions will have its next instruction as the successor, 
except jump instructions, return instructions, and instructions 
that throw an exception. 

Type Systems The transfer rules of DEX are defined in 
terms of registers typing rt : {TZ S) instead of stack typing. 
Note that this registers typing is total w.r.t. the registers used 
in the method. To be more concrete, if a method only uses 
16 registers then rt is a map for these 16 registers to security 
levels, as opposed to the whole number of 65535 registers. 

The transfer rules also come equipped with a security 
policy for fields ft ; JF ^ and at ; W 5®’'*. Some 
of the transfer rules for DEX instructions are contained in 
Figure Full transfer rules are contained in Appendix 

The typability of the DEX closely follows that of the JVM, 
except that the relation between program points is i i- RTi => 
rt,rt £ RTj. The definition of £ is also defined in terms of 
point-wise registers. For now we assume the existence of safe 
CDR with the same definition as that of the JVM side. We 
shall see later how we can construct a safe CDR for DEX 
from a safe CDR in JVM. Formal definition of typable DEX 
method; 

Definition IV.l (Typable method). A method m is typable w.r.t. 
a method signature table T, a global field policy ft, a policy 
sgn, and a CDR regionm ■ W pi'P'P) if there exists a 
security environment se ■ VV S and a function RT : VV 
{TZ -> iS) s.t. RTi = ka and for all i,j € W, e € {Norm + C}: 

• i i->-® j implies there exists rt 6 {TZ S) such that E, 
ft, region, se, sgn, i h® RTi =► rt and rt £ RTj; 

• z 1 -^® implies E, ft, region, se, sgn, i i-® RR 

Following that of the JVM side, what we want to establish 
here is not just the typability, but also that typability means 












Pm[i] = const (r,z;) 

Pm[i] = return(rs) se(z) u rt{rs) < kr[n\ 

z H rf => rf ® {r 1-^ ■se(z)} 

i\- rt ^ 

P[z] = move(r, Ts) 

Pm[i] = hinop{op,r,ra,rb) 

z H rf => rf ® {r 1-^ (rf(rs) U se(z))} 

z h- rf => r< ® {r 1-^ {rt(ra) u rt{rb) u se(z))} 

Pm[z] = goto(j) Pm[i 

] = ifeq(r, t) 'ij, e region(z, Norm), se(z) u r<(r) < se(j') 

i rt ^ rt 

i rt ^ rt 


Fig. 6; DEX Transfer Rule (Selected) 


non-interference. As in the JVM, the notion of non-interference 
relies on the definition of indistinguishability, while the notion 
of value indistinguishability is the same as that of JVM. 

Definition IV.2 (Registers indistinguishability). For p, p' : 
(7?. ^ "F) and rt,rt' : (TZ S), we have p ,i 3 p' 

iff Va; i locR, rt{x) = rt'{x) = k,k ^ kohs or rt{x) = k, 
rt'{x) = k', k < kohs, k' < fcobsj p{x) = p'{x) = v. where 
V eV, and k, k' e S. 

Definition IV.3 (Object indistinguishability). Two objects 
Oi, 02 6 O are indistinguishable with respect to a partial 
function (3 e C ^ C (noted by Oi *^ 2 ) if and only if 

Oi and 02 are objects of the same class and 0 \.f 02 -f for 

all fields f € dom(oi) s.t. ft(/) < fcobs- 

Definition IV.4 (Array indistinguishability). Two arrays 
01,02 e A are indistinguishable w.r.t. an attacker level kohs 
and a partial function e C ^ C (noted by oi 02 ) 

if and only if oi.length = 02 .length and, moreover, if 
at(oi) < kohs, then oi[z] 02 ( 1 ] for all i such that 
0 < z < oi.length. 

Definition IV.5 (Heap indistinguishability). Two heaps hi 
and ft -2 ore indistinguishable with respect to an attacker level 
kohsOnd a partial function /3 e C ^ C, written hi ^ 2 . 

if and only if : 

• is a bijection between dom(/3) and rng(/3); 

• dom(/3) £ dom(/ii) and rng(,0) £ dom(/z 2 ); 

• V( 6 dom(/?),/zi(/) /z 2 (/?(()) where hffl) 

and ft-2(/?(0) ore either two objects or two arrays. 

Definition IV.6 (Output indistinguishability). Given an at¬ 
tacker level kohs, o partial function j3 e C ^ C, an output 
level kr, the indistinguishability of two final states in method 
m is defined by the clauses : 

hi ^kchs,P ^2 /c7.[tz] £ kohs ^ tzi V2 

~feobB,/3.fc; i^2,h2) 

'^kohs.P ^2 (class(/zi (( 1 ) ) . /b) € kr k £ kohs ^p ^2 


kl '^kohs.P ^2 (class(/zi (( 1 )) . fc) € kr k kohs 

{{h),hi) '^k„,,,,p,kr ('^ 2 ,^ 2 ) 

kl ^kohs,P ^2 (class(/z2((2)) * k^ € kr k kohs 

{vi,hi) -k„^^^p^kr ((^ 2 ),/i 2 ) 

ki ^fcobs,/3 7 z 2 (class(/zi(( 1 )) . ki^ € kr ki ^ kohs 

(class(/z2((2)) : ^ 2 ) 6 fcr ^ kohs 
m,hi)-,^^^^p^p^i{i2),h2) 

where indicates logical implication. 

Definition IV.7 (Non-interferent DEX method). A method m 
is non-interferent w.r.f. a policy ka ->• kr, if for every attacker 
level kohs, every partial function fi € C ^ C and every pi,p 2 6 
X ^V, hi,h 2 , Ti'i, /12 s Heap, vi,V 2 + C s.t 

{l,pi,hi)--r(j^vi,h'i Til ^2 

(1,P2,^2) t^2,/l2 P2 

there exists a partial function ff e C ^ C s.t. /3 £ /3' and 

{Vl,h'i) -k^^^^ppkf {V2,h'2) 

Definition IV.8 (Side effect preorder). Two heaps /ii,/i 2 s 
Heap are side effect preordered with respect to a security 
level k e S (written as hi <k ^ 12 ) if and only if doni{hi) £ 
dom(/i 2 ) and hi{l).f = h 2 {l).f for all location I € dom(ft,i) 
and all fields f & T such that k ^ ft(/). 

Definition IV.9 (Side effect safe). A method m is side-effect- 
safe with respect to a security level kh if for all registers in 
p e TZ ^ V,dom(p) = locR, for all heaps h, h' e Heap and 
value o 6 V, (1, p, h) v, h' implies h <k^ h' . 

Definition IV.IO (Safe DEX method). A method m is safe 

w.r.t a policy ka kr if m is side-effect safe w.r.t kh and m 
is non-interferent w.r.t. ka kr. 

Definition IV.ll (Safe DEX program). A program is safe w.r.f. 
a table E of method signatures if every method m is safe w.r.t. 
all policies in Policiesr{m). 

Theorem IV.l. Let P be a DEX typable program w.r.t safe 
CDRs (regionjn, jun^n) and a table V of method signatures. 
Then P is safe w.r.t E. 




V. Examples 

Throughout our examples we will use two security levels 
L and H to indicate low and high security level respectively. 
We start with a simple example where a high guard is used to 
determine the value of a low variable. 

Example V.l. Assume that local variable I is H and local 
variable 2 is L. For now also assume that rs is the start of the 
registers used to simulate the stack in the DEX instructions. 
Consider the following JVM bytecode and its translation. 


level, therefore rt{r 4 ) = H. Then, at the iput(r 5 ,r 4 ,/) we 
won’t be able to satisfy Lu H u L < L. 

This last example shows that the type system also handles 
information flow through exceptions. 

Example V.3. Assume that ka = {ri H,r 2 L,T 3 H} 
and kr = {n L,e 1 -^ H}. Handler(^ 2 ,up) = Ih, 

and for any e, Handler(l 2 , e) f. The following JVM bytecode 
and its translation will be rejected by the typing system for the 
JVM bytecode. 


push 0 

const (r 3 , 0 ) 

store 2 

move(r 2 ,r 3 ) 

load 1 

move(r 3 ,ri) 

ifeq li 

ifeq(r 3 ,(i) 

push 1 

const (r 3 , 1 ) 

store 2 

move(r 2 ,r 3 ) 


li ... li ■■ 

In this case, the type system for the JVM bytecode will reject 
this example because there is a violation in the last store 2 
constraint. The reasoning is that se{i) for push 1 will be 
H, thus the constraint will he H u H < L which can not 
be satisfied. The same goes for the DEX instructions. Since 
ra gets its value from ri which is H, the typing rule for 
ifeq(r 3 ,/i) states that se in the last instruction will be H. 
Since the last move instruction is targetting variables in the 
local variables side, the constraint applies, which states that 
H u H < L which also can not be satisfied, thus this program 
will be rejected by the DEX type system. 

The following example illustrates one of the types of the 
interference caused by modification of low fields of a high 
object aliased to a low object. 

Example V.2. Assume that ka = {ri 1-^ H,r 2 H, i-> L) 
(which means local variable 1 is high, local variable 2 is high 
and local variable 3 is low). Also the field / is low (ft(/) = L). 



load 1 

move(r 4 , ri) 

• 

ifeq I 2 

h'. ifeq(r4,(2) 


new C 

new(r 4 , C) 


store 3 

move(r 3 ,r 4 ) 


load 3 

move(r 4 , r 3 ) 

h • 

invokevirtual m 

I 2 ■ invoke(l,TO,r 4 ) 


push 0 

const(r 4 , 0 ) 


return 

ret move(ro,r 4 ) 
return(ro) 

ih-- 

push 1 

Ih'- const(r 4 ,ri) 


return 

move(ro,r 4 ) 



goto(ref) 

The reason 

is that the typing constraint for the invokevirtual 


will be separated into several tags, and on each tag of execution 
we will have se as high (because the local variable 3 is high). 
Therefore, when the program reaches return 2 (line 8 and 
10) the constraint is violated since we have kr\n] = L, thus 
the program is rejected. Similar reasoning holds for the DEX 
type system as well, in that the invoke will have se high 
because the object on which the method is invoked upon is 
high, therefore the typing rule will reject the program because 
it can not satisfy the constraint when the program is about to 
store the value in local variable 2 (constraint H < L is violated, 
where H comes from lub with se). 

VI. Translation Phase 


new C 
store 3 
load 2 
h ■■ ifeq I 2 
new C 
goto I 3 
I 2 ■ load 3 
(3 : store 1 
load 1 
push 1 
putfield / 


new(r 4 , C) 
move(r 3 , r 4 ) 
move(r 4 , r 2 ) 

: ifeq(r4,(2) 
new(r 4 , C) 
gotoik) 

l2- move(r4,r3) 
(3: move(ri,r4) 
move(r4,ri) 
const (rs, 1 ) 
iput(r5,r4,/) 


The above JVM bytecode and its translation will be rejected by 
the type system for the JVM bytecode because for putfield / 
at the last line there is a constraint with the security level of the 
object. In this case, the load 1 instruction will push a reference 
of the object with high security level, therefore, the constraint 
that Lu Hu L < L can not be satisfied. The same goes for the 
DEX type system, it will also reject the translated program. 
The reasoning is that the move(r 4 ,ri) instruction will copy 
a reference to the object stored in ri which has a high security 


Before we continue to describe the translation processes, 
we find it helpful to first define a construct called the basic 
block. The Basic block is a construct containing a group of 
code that has one entry point and one exit point (not necessarily 
one successor/one parent), has parents list, successors list, 
primary succesor, and its order in the output phase. There are 
also some auxilliary functions : 


BMap 

SBMap 


TSMap 


NewBlock 


is a mapping function from program pointer in 
JVM bytecode to a DEX basic block. 

Similar to BMap, this function takes a program 
pointer in JVM bytecode and returns whether 
that instruction is the start of a DEX basic block. 
A function that maps a program pointer in JVM 
bytecode to an integer denoting the index to the 
top of the stack. Initialized with the number of 
local variables as that index is the index which 
will be used by DEX to simulate the stack. 

A function to create a new Block and associate 
it with the given instruction. 


The DEX bytecode is simulating the JVM bytecode al¬ 
though they have different infrastructure. DEX is register-based 



whereas JVM is stack-based. To bridge this gap, DEX uses 
registers to simulate the stack. The way it works : 

• I number of registers are used to hold local variables. 
(1,... ,1). We denote these registers with locR. 

• Immediately after I, there are s number of registers 
which are used to simulate the stack {I + 1 ,... ,l + s). 

Note that although in principal stack can grow indefinitely, it 
is impossible to write a program that does so in Java, due 
to the strict stack discipline in Java. Given a program in JVM 
bytecode, it is possible to statically determine the height of the 
operand stack at each program point. This makes it possible 
to statically map each operand stack location to a register in 
DEX (cf. TSMap above and Appendix |A-C| l; see ll231 for a 
discussion on how this can be done. 

There are several phases involved to translate JVM 
bytecode into DEX bytecode; 

StartBlock: Indicates the program point at which the instruc¬ 
tion starts a block, then creates a new block for each of these 
program points and associates it with a new empty block. 

TraceParentChUd: Resolves the parents successors (and pri¬ 
mary successor) relationship between blocks. Implicit in this 
phase is a step creating a temporary return block used to hold 
successors of the block containing return instruction. At this 
point in time, assume there is a special label called ret to 
address this temporary return block. 

The creation of a temporary return block depends on 
whether the function returns a value. If it is return void, then 
this block contains only the instruction return-void. Otherwise 
depending on the type returned (integer, wide, object, etc), 
the instruction is translated into the corresponding move and 
return. The move instruction moves the value from the 
register simulating the top of the stack to register 0. Then 
return will just return tq. 

Translate: Translate JVM instructions into DEX instructions. 

PickOrder; Order blocks according to “trace analysis”. 

Output; Output the instructions in order. During this phase, 
goto will be added for each block whose next block to output 
is not its successor. After the compiler has output all blocks, 
it will then read the list of DEX instructions and fix up the 
targets of jump instructions. Einally, all the information about 
exception handlers is collected and put in the section that deals 
with exception handlers in the DEX file structure. 

Definition VI.l (Translated JVM Program). The translation of 
a JVM program P into blocks and have their JVM instructions 
translated into DEX instructions is denoted by [[fjj, where 

|[PJJ = Translate(TraceParentChild(StartBlock(P))). 

Definition VI.2 (Output Translated Program). The output of 
the translated JVM program [[PJ] in which the blocks are 
ordered and then output into DEX program is denoted by 
^here 

[[[[Pjjfl = Output(PickOrder([[Pj])). 


Definition VI.3 (Compiled JVM Program). The compilation 
of a JVM program P is denoted by |P], where 

M = mi 

Details for each of the phase can be seen in appendix 

VII. Proof that Translation Preserves Typability 

A. Compilation of CDR and Security Environments 

Since now we will be working on blocks, we need to know 
how the CDRs of the JVM and that of the translated DEX are 
related. Eirst we need to define the definition of the successor 
relation between blocks. 

Definition VII.l (Block Successor). Suppose a>->- b and a and 
b are on different blocks. Let Ba be the block containing a and 
Bb be the block containing b. Then Bi, will be the successor 
of Ba denoted by abusing the notation Ba Bf,. 

Before we continue on with the properties of CDR and 
SOAP, we first need to define the translation of region and 
jun since we assume that the JVM bytecode comes equipped 
with region and jun. 

Definition VII.2 (Region Translation and Compilation). Given 
a JVM region(i, t) and P[i] is a branching instruction, let it, 
be the program point in [[ij] such that Pdex[^6] A o branching 
instruction, then 

[[region(i,T)jJ = region(4, [[rjj) = Uj€region(*,r)[L j J| 
and 

|region(i,T)] = region(i6, |t]) = Uj^regionCi.r) [jl 

Definition VII.3 (Region Translation and Compilation for 
invoke). 'Ji.PDEx\i] = invoke, i + 1 € region(*, Norm) 
(i + 1 will be the program point for moveresult ). 

Definition VII.4 (Region Translation and Compilation for 
handler). e region(i,T), let if. be the instruction in 

[[P[z]JJ that possibly throws, then 

handler(ie, t) € region(ie, t) in [[PJ] 
and 

handler ( pell, r) e region(pe]l, t) in |P] 

(note that the handler will point to moveexception). 
Definition VII.5 (Region for appended goto instruction). 

V6 6 |[Pjj. Po£x[[[6.1astAddress]l + 1] = goto 

^ (V.i € PP£)£;{.&.last Address € region(i,T) 
^ (p.last Address]] + 1) e region(i,r)) 

where -> indicates logical implication. 

Definition VII.6 (Junction Translation and Compilation). 
^fj-j = jFni(*iT), let ib be in [[P[i]J] that branch then 

|[jJ|[0] = jun(pj][i6],r) in [[Pj] 
and 

[p|[0]l=jun([P|[*,]l,r) in [PJ. 

Definition VII.7 (Security Environment Translation and Com¬ 
pilation). Vi € W,j 6 pjj.se(j) = se{i) in [[PJ] and 
Vi € PV,j € pj].se(][j]]) = se(i) in |P]. 

Lemma VII.l (SOAP Preservation). The SOAP properties are 
preserved in the translation from JVM to DEX, i.e. if the JVM 




program satisfies the SOAP properties, so does the translated 
DEX program. 

B. Compilation Preserves Typability 

There are several assumption we make for this compilation. 
Firstly, the JVM program will not modify its self reference for 
an object. Secondly, since now we are going to work in blocks, 
the notion of se, S, and RT will also be defined in term of 
this addressing. A new scheme for addressing blockAddress 
is defined from sets of pairs {bi,j), bi e blockindex, a set of 
all block indices (label of the first instruction in the block), 
where Vi e 'PV.3bi,j. s.t.bi + j = i. We also add additional 
relation to denote the reflexive and transitive closure of 
=> to simplify the typing relation between blocks. 

We overload [[.JJ and |.] to also apply to stack type to 
denote translation from stack type into typing for registers. 
This translation basically just maps each element of the stack 
to registers at the end of registers containing the local variables 
(with the top of the stack with larger index, i.e. stack expanding 
to the right), and fill the rest with high security level. More 
formally, if there are n local variables denoted by vi,... ,Vn 
and stack type with the height of m (0 denotes the top of 
the stack), and the method has o registers (which corresponds 
to the maximum depth of the stack), then |sf] = {tq 
fca(t;i),...,r„_i ka{Vn),rn st[m- l],...,rn+m-l 
st[Q],rn+m H, ■ ■ ■ ,^0 H}. Lastly, the function [[.]] is also 

overloaded for addressing {bi,i) to denote abstract address 
in the DEX side which will actually be instantiated when 
producing the output DEX program from the blocks. 

Due to the way stack type is translated to registers typing, 
we find it beneficial to introduce a simple lemma that can 
be proved trivially (by structural induction and definition) in 
regards to the rti E rt 2 relation. In particular this lemma will 
relates the registers metioned in rti but are not mentioned in 
rt2. 

Lemma VII.2 (Registers Not in Stack Less Equal). Let the 
number of local variables be locN. For any two stack types 
sfi,5^2,length(sfi) = n,length(sf 2 ) = rn,m < n, any 
register x € {riocN+m+i, ■ ■ ■ ,riocN+m+n}, and register types 
rti = lisfiJJ ,■'’^2 = lisf 2 jj we have that rti(x) < rt 2 {x). 

Definition VII.8 ([[excAnalysis]] and |excAnalysis]). 

Vm € Ad.[[excAnalysis(TO)J] = exc Analysis (to) in [[PJ] 

and 

Vto 6 AJ.|excAnalysis(TO)| = excAnalysis(TO) in |P|. 

Definition VII.9 ([[classAnalysis]] and [classAnalysis]). 
Let e be the index of the throwing instruction from ][i]J. 

/ Vto € 6 PP.][classAnalysis(TO, ][z]][e])]] = \ 

\ classAnalysis(TO, i) in ][P]] ) 

and 

/ Vto 6 € PP.][classAnalysis(TO, ][][i]][e]]])]] = \ 

\ classAnalysis(TO, i) in |P] )' 

Definition VII.IO ([[E]] and [E]). Vto e 7W.][r[][TO]]]]J = 
r[TO] in ][P]] and Vto 6 AI.|r[|TO]]] = r[TO] in |P]. 

Definition VII.ll. Vi 6 PP,PT|,j|[o] = [[S',]]. 


that does not modify the block structure can be proved using 
Lemma VII. 3[ Lemma VII.4 and Lemma VII.5 to prove the 
typability of register typing. 


Initially we state lemmas saying that typable JVM instruc¬ 
tions will yield typable DEX instructions. Paired with each 
normal execution is the lemma for the exception throwing one. 
These lemmas are needed to handle the additional block of 
moveexception attached for each exception handler. 

Lemma VII.3. For any JVM program P with instruction Ins 
at address i and tag Norm, let the length of ][/ns]J be n. Let 
PT|jj|[g] = [[^i]]. If according to the transfer rule for P[i] = 
Ins there exists st s.t. i Si =>■ st then 

I V0< j < (n- l).3rf'.][i]][j] \ 

and 

3rL][i]][n- 1] => rt,rt E ][sf]] 

according to the typing rule(s) of ][/ns]]. 

Lemma VII.4. For any JVM program P with instruction Ins 
at address i and tag t + Norm with exception handler at 
address ig- Let the length of ][/ns]] until the instruction that 
throws exception r be denoted by n. Let (&e,0) = ][ie]J be 
the address of the handler for that particular exception. If 
Si ^ st according to the transfer rule for Ins, then 

( V0< j < (n-l).3rf'.][i]][j] \ 

V ^%JIL] ^ - ^%JIL+1] / 

and 

3rL][i]][n- 1] ^ rt,rt £ RT(^befi) 

and 

3rt.(6e,0) RT(^be,o) rt,rt E ][sf]J 

according to the typing rule(s) of the first n instructions in 
][Jns]] and moveexception. 

Lemma VII.5. Let Ins be an instruction at address i, j, 
st. Si and Sj are stack types such that i Si ^ st, .st E 
Sj. Let n be the length of ][/ns]]. Let PPpjijQ] = [[S^]], let 
^^1L3[0] “ registers typing obtained from the 

transfer rules involved in ][Jns]]. Then rt E PPy^jj|[o]. 


We need an additional lemma to establish that the con¬ 
straints in the JVM transfer rules are satisfied after the trans¬ 
lation. This is because the definition of typability also relies on 
the constraint which can affect the existence of register typing. 

Lemma VII.6. Let Ins be an instruction at program point 
i. Si its corresponding stack types, and let PT|jj|[o] = [[S^]]. 
If P[i\ satisfy the typing constraint for Ins with the stack 
type Si, then 'J{bj,j) e ][j]].PD£;x[fej, j] will also satisfy the 
typing constraints for all instructions in ][/ns]] with the initial 
registers typing RT^q^oy 


Using the above lemmas, we can prove the lemma that all 
the resulting blocks will also be typable in DEX. 

Lemma VII.7. Let P be a Java program such that 

j.3st.i Si ^ st and st E Sj 

Then ][P]] will satisfy 


The idea of the proof that compilation from JVM bytecode 
to DEX bytecode preserves typability is that any instruction 


1) for all blocks bi,bj s.t. bi bj, 3rtb. s.t RTsbi =>■* 
rtb,rtb E RTsbj,' and 







2 ) 


where 


'ibifj 

6 bi. s.t. 


{bi,j).3rt. s.i 

RT(bi,i) 

=► rt, rt E 

= RT{bi,j) 



RTsbi 


with 


= (6i,0) 

RTsbj 

= isd 

with 

bt - 

= 

RT(bi,i 

) = 

with 


= {bi,i) 

RR(bi,j 

0 = 

with 

b'l 

= {bj,j) 


After we established that the translation into DEX instruc¬ 
tions in the form of blocks preserves typability, we also need 
ensure that the next phases in the translation process also 
preserves typability. The next phases are ordering the blocks, 
output the DEX code, then fix the branching targets. 


not identified special object and method invocation for this 
message passing mechanism in the bytecode. 

In this study, we have not worked directly with the dx tool; 
rather, we have written our own DEX compiler in Ocaml based 
on our understanding of how the actual dx tool works. This 
allows us to look at several sublanguages of DEX bytecode 
in isolation. The output of our custom compiler resembles the 
output from the dx compiler up to some details such as the 
size of register addressing. Eollowing the Compcert project 
Ell, ESI, we would ultimately like to have a fully certified 
end to end compiler. We leave this as future work. 
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Lemma VII.8. Let [[PJ] be typable basic blocks resulting from 
translation of JVM instructions still in the block fonn, i.e. 

[[PJ] = Translate(TraceParentChild(StartBlock(P))). 

Given the ordering scheme to output the block contained in 
PickOrder, if the starting block starts with flag 0 fP(o,o) = Oj 
then the output |P] is also typable. 


Einally, the main result of this paper in that the compilation 
of typable JVM bytecode will yield typable DEX bytecode 
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Typable DEX bytecode will also have the non-interferent 
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according to DEX. 


Theorem VII.l. Let P be a typable JVM bytecode according 
to its safe CDR (region, junj, PA-Analysis (classAnalysis 
and excAnalysis), and method policies E, then |P] accord¬ 
ing to the translation scheme has the property that 


yiyj e PPdex- s.t. i i-*- j.3rt. s.t. RTi => rt,rt E RTj 
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Eurthermore, the typability of the DEX program also implies 
its non-interference. We provide a proof-of-concept implemen¬ 
tation illustrating the feasibility of the idea. This opens up the 
possibility of reusing analysis techniques applicable to Java 
bytecode for Android. As an immediate next step for this 
research, we plan to also take into account the optimization 
done in the dx tool to see whether typability is still preserved 
by the translation. 

Our result is quite orthogonal to the Bitblaze project 
where they aim to unify different bytecodes into a common 
intermediate language, and then analyze this intermediate 
language instead. At this moment, we still do not see yet 
how DEX bytecode can be unified with this intermediate 
language as there is a quite different approach in programming 
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paradigm which has to be built into the Bitblaze infrastructure. 
This problem with message passing paradigm is essentially 
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Appendix A 
Translation Appendix 


This section details compilation phases described in Sec- 


VI in more details. We first start this section by detailing 


tion 

the structure of basic block. BasicBlock is a structure of 


{parents] succs] pSucc; order] insn} 

which denotes a structure of a basic block where parents £ Z 
is a set of the block’s parents, succs Q Z is a set of the block’s 
successors, pSucc 6 Z is the primary successor of the block 
(if the block does not have a primary successor it will have 
-1 as the value), order e Z is the order of the block in the 
output phase, and insn u DEXins is the DEX instructions 
contained in the block. The set of BasicBlock is denoted as 
BasicBlocks-When instatiating the basic block, we denote the 
default object NewBlock, which will be a basic block with 

[parents = 0; succs = 0; pSucc = -1; order = -1; insn = 0} 


Throughout the compilation phases, we also make use of 
two mappings PMap : W W and BMap : W 
BasicBlocks. The mapping PMap is a mapping from a 
program point in JVM to a program point in JVM which 
starts a particular block, e.g. if we have a set of program 
points {2,3,4} forming a basic block, then we have that 
PMap(2) = 2, PMap(3) = 2, and PMap(4) = 2. BMap 
itself will be used to map a program point in JVM to a basic 
block. 


A. Indicate Instructions starting a Block (StartBlock) 

This phase is done by sweeping through the JVM instruc¬ 
tions (still in the form of a list). In the implementation, this 
phase will update the mapping StartBlock. Apart from the 
first instruction, which will be the starting block regardless 
of the instruction, the instructions that become the start of a 
block have the characteristics that either they are a target of a 
branching instruction, or the previous instruction ends a block. 

Case by case translation behaviour : 

• P[i] is Unconditional jump (goto t) : the target 
instruction will be a block starting point. There is 
implicit in this instruction that the next instruction 
should also be a start of the block, but this will be 
handled by another jump. We do not take care of the 
case where no jump instruction addresses this next 
instruction (the next instruction is a dead code), i.e. 

o BMap ffi {f 1-^ NewBlock}] and 

o PMap ® [t t] 

• P[i] is Conditional jump (ifeq t) : both the target 
instruction and the next instruction will be the start of 
a block, i.e. 

o BMap ffi {f 1-^ NewBlock, (f + 1 ) i-^ 

NewBlock}] and 

o PMap ® {f i-s- f, (i + 1) !-!► (f + 1)}. 

• P[i] is Return; the next instruction will be the start 
of a block. This instruction will update the mapping 
of the next instruction for BMap and SB Map if 
this instruction is not at the end of the instruction list. 
The reason is that we already assumed that there is 


no dead code, so the next instruction must be part of 
some execution path. To be more explicit, if there is 
a next instruction i + 1 then 

o BMap ffi {(i + 1) NewBlock}] and 
o PMap ® {(f + 1) i-s- (i + 1)1 

• P[i] is an instruction which may throw an exception 
; just like return instruction, the next instruction will 
be the start of a new block. During this phase, there 
is also the setup for the additional block containing 
the sole instruction of moveexception which serves 
as an intermediary between the block with throwing 
instruction and its exception handler. Then for each 
associated exception handler, its: 

startPC program counter (pc) which serves as the start¬ 
ing point (inclusive) of which the exception 
handler is active; 

endPC program counter which serves as the ending 
point (exclusive) of which the exception han¬ 
dler is active; and 

handlerPC program counter which points to the start of 
the exception handler 

are indicated as starting of a block. For handler 
h, the intermediary block will have label intPC = 
maxLabel + /i.handlerPC. To reduce clutter, we 
write sPC to stand for /i.startPC, ePC to stand 
for Ii.endPC, and hPC to stand for /i.handlerPC. 
o JUsAap® {{i+1) 1 -^ NewBlock}] 
o BMap ® [sPC NewBlock}] 

o BMap ® [ePC NewBlock}] 

o BMap ® [hPC NewBlock}] 

o BMap ® [int NewBlock}] 
o PMap ® {(/+ 1) !->• (i-r 1)}; 
o PMap ® (sPC 1 -^ sPC); 

o PMap ® {ePC ePC}; 

o PMap ® {/iPC 1-^/iPC}; 

o PMap ® {in/mf}; 

• P[z] is any other instruction : no changes to BMap 
and PMap. 


B. Resolve Parents Successors Relationship 
(TraceParentChild) 

Before we mention the procedure to establish the parents 
successors relationship, we need to introduce an additional 
function getAvailableLabel. Although defined clearly in 
the dx compiler itself, we’ll abstract away from the detail 
and define the function as getting a fresh label which will not 
conflict with any existing label and labels for additional blocks 
before handler. These additional blocks before handlers are 
basically a block with a single instruction moveexception 
with the primary successor of the handler. Suppose the handler 
is at program point i, then this block will have a label of 
maxLabel+i with the primary successor i. Furthermore, when 
a block has this particular handler as one of its successors, 
the successor index is pointed to maxLabel + i (the block 
containing moveexception instead of i). In the sequel, 
whenever we say to add a handler to a block, it means that 
adding this additional block as successor a of the mentioned 
block, e.g. in the JVM bytecode, block i has exception handlers 
at j and k, so during translation block i will have successors 



of {maxLabel + j, max Label + k], block j and k will have 
additional parent of block maxLabel + j and maxLabel + k, 
and they each will have block i as their sole parent. 

This phase is also done by sweeping through the JVM 
instructions but with the additional help of BMap and PMap 
mapping. Case by case translation behaviour : 

• P[i] is Unconditional jump (goto t) : update the suc¬ 
cessors of the current block with the target branching, 
and the target block to have its parent list include the 
current block, i.e. 

o BMap(PMap(i)).succs u {f}; 
o BMap(PMap(z)).pSucc = f; and 

o BMap(f).parents u {PMap(i)} 

• P[i] is Conditional jump (ifeq t) : since there will be 
2 successors from this instruction, the current block 
will have additional 2 successors block and both of 
the blocks will also update their parents list to include 
the current block, i.e. 

o BMap(PMap(i)).succs u {i + 1, f}; 
o BMap(PMap(z)).pSucc = i + 1; 
o BMap(i -I- 1).parents u {PMap(i)}; and 

o BMap(f).parents u {PMap(i)} 

• P[i] is Return ; just add the return block as the 
current block successors, and also update the parent 
of return block to include the current block, i.e. 

o BMap(PMap(i)).succs u {ref}; 
o BMap(PMap(z)).pSucc = ref; and 
o BMap(ref).parents u {PMap(f)} 

• P[i] is one of the object manipulation instruction. The 
idea is that the next instruction will be the primary 
successor of this block, and should there be exception 
handler(s) associated with this block, they will be 
added as successors as well. We are making a little 
bit of simplification here where we add the next 
instruction as the block’s successor directly, i.e. 

o BMap(PMap(f)).succs u {f- 1 -1}; 
o BMap(PMap(f)).pSucc = f + 1; 
o BMap(f + 1). parents u {PMap(i)}; and 
o for each exception handler j associated with i, 

let intPC = maxLabel + j.handlerPC and 

hPC = j.handlerPC; 

■ BMap(PMap(i)).succs u {mfPC}; 

■ BMap(PMap(i)).handlers u {j}; 

■ BMap(mfPC').parents u {PMap(z)} 

■ BMap(mfPC').succs u {/iPC} 

■ BMap(mfPC').insn = 

{ moveexcept ion } 

■ BMap(/iPC').parents u {mfPC} 

In the original dx tool, they add a new block to 
contain a pseudo instruction in between the current 
instruction and the next instruction, which will be 
removed anyway during translation 


the additional block is bypassed in object manipulation 
instruction, this time we really add a block with an 
instruction moveresult (if the method is returning 
a value) with a fresh label I = getAvailableLabel 
and the sole successor of f + 1. The current block will 
then have I as it’s primary successor, and the next 
instruction (i+1) will have I added to its list of parents, 
i.e. 

o I = getAvailableLabel; 
o BMap(PMap(i)).succs u {(}; 
o BMap(PMap(f)).pSucc = f; 

o BMap(PMap(f)).parents = {f}; 

o BMap ffi {Z NewBlock}-, 
o BMap(Z).succs = {i-I-1}; 
o BMap(Z).pSucc = (f + 1); 
o BMap(Z).insn = 

{moveresult} 

o BMap(j + 1).parents u {f}; and 
o for each exception handler j associated with i, 
let intPC = maxLabel + j.handlerPC and 
hPC = j.handlerPC; 

■ BMap(PMap(i)).snccs u {mfPC}; 

■ BMap(PMap(f)).handlers u (j); 

■ BMap(mfPC).parents u {PMap(f)} 

■ BMap(mfPC) .succs u {hPC} 

■ BMap(mfPC).insn = 

{ moveexcept ion} 

■ BMap(/iPC).parents u {intPC} 

• P[i] is throw instruction. This instruction only add 
the exception handlers to the block without updating 
other block’s relationship, i.e. if the current block is 

i, then for each exception handler j associated with i, 
let intPC = maxLabel + j.handlerPC and hPC = 

j. handlerPC: 

o BMap(PMap(i)).succs u {infPC}; 

o BMap(PMap(f)).handlers u {j}; 

o BMap(fnfPC).parents u {PMap(f)} 

o BMap(fnfPC).succs u {/iPC} 

o BMap(fnfPC).insn = 

{ moveexcept ion } 

o BMap(/iPC).parents u {mfPC} 

• P[i] is any other instruction ; depending whether the 
next instruction is a start of a block or not. 

o If the next instruction is a start of a block, 
then update the successor of the current block 
to include the block of the next instruction and 
the parent of the block of the next instruction 
to include the current block i.e. 

■ BMap(PMap(i)).snccs u {f + 1}; and 

■ BMap(f + 1).parents u {PMap(j)} 

o If the next instruction is not start of a block, 
then just point the next instruction to have 
the same pointer as the current block, i.e. 
PMap(f + 1) = PMap(f) 


• P[i] is method invocation instruction. The treatment 
here is similar to that of object manipulation, where 
the next instruction is primary successor, and the 
exception handler for this instruction are added as 
successors as well. The difference lies in that where 


C. Reading Java Bytecodes (Translate) 

Table list the resulting DEX translation for each of 
the JVM bytecode instruction listed in section III The full 
translation scheme with their typing rules can be seen in 





Translation 

Side effect 

llpushJI 

= const(r(TSi), n) 


TS(i+ 1) = TS(i) + 1 

Ipopl 

= 0 


TS(i+ 1) = TS(i) - 1 

[load 

= move(r(TSi), Px) 


TS(i+ 1) = TS(i) + 1 

[store a:| 

= move(rx, r(TSi - 1)) 


TS(i+ 1) = TS(i) - 1 

II binop op|| 

= binop(op, r(TSi - 2), r(TSi - 2), 


TS(i+ 1) = TS(i) - 1 


r(TS,-1)) 



[swap] 

= move(r(TSi),r(TSi - 2)) 


TS(i+ 1) = TS(i) 


move(r(TSi + 1), r-(TSi - 2)) 




move(r(TSi - l),r-(TSi + 1)) 




move(r(TSi -2),r-(TSi)) 



[goto t] 

= 0 


TS(t) = TS(i) 

|ifeq t] 

= ifeq(r(TSi - l).t) 


TS(i+ 1) = TS(i) - 1 




TS(t) = TS(i) - 1 

|return| 

= move(ro, r(TSi - 1)) 




return(ro) 




goto(ret) 



[new C| 

= new(r(TSi - 1),C) 


TS(i+ 1) = TS(i) + 1 

Igetfleld /] 

= iget(r(TSi-l).r(TSi-l),/) 


TS(i+ 1) = TS(i) + 1 

iputfleld /] 

= iput(r(TSi - l),r-(TSi-2)./) 


TS(i+ 1) = TS(i) -2 

[newarray 

= newarray(r(TSi - 1), r(TSi - l),t) 


TS(i+ 1) = TS(i) 

[array lengthU 

= arraylength(r(TSi - l),r(TSi - 1)) 


TS(i+ 1) = TS(i) 

[arrayloadj 

= aget(r(TSi-2),r-(TSi-2).r-(TSi - 

1)) 

TS(i+ 1) = TS(i) - 1 

[arraystore| 

= aput(r-(TSi - l),r(TSi - 3),r(TSi - 

2)) 

TS(i+ 1) = TS(i) -3 

[invoke m| 

= invoke(n, m, p) 


L = getAvailablebabel 


moveresult(r‘(TSi - n)) at block 1 


TS(i+ 1) = TS{i)-n 

[throw] 

= throw(r(TSi - 1)) 




TABLE I; Instruction Translation Table 


table 1^ in the appendix. A note about these instructions is that 
during this parsing of JVM bytecodes, the dx translation will 
also modify the top of the stack for the next instruction. Since 
the dx translation only happens in verified JVM bytecodes, we 
can safely assume that these top of the stacks will be consistent 
(even though an instruction may have a lot of parents, the 
resulting top of the stack from the parent instruction will be 
consistent with each other). To improve readability, we abuse 
the notation r{x) to also mean r^. 

D. Ordering Blocks (PickOrder) 

The “trace analysis” itself is quite simple in essence, that 
is for each block we assign an integer denoting the order of 
appearance of that particular block. Starting from the initial 
block, we pick the first unordered successor and then keep on 
tracing until there is no more successor. 

After we reached one end, we pick an unordered block 
and do the “trace analysis” again. But this time we trace its 
source ancestor first, by tracing an unordered parent block and 
stop when there is no more unordered parent block or already 
forming a loop. Algorithmic describes how we implement this 
“trace analysis”. 


Algorithm 1 PickOrder(6Zocfcs) 
order := 0; 

while there is still block x 6 blocks without order; do 
var ■■= Pick Starting Point{x, {x}); 
order = TraceSuccessors{source,order); 

return order; 


• Pick Starting Point 

This function is a recursive function with an auxiliary 
data structure to prevent ancestor loop from viewpoint 
of block X. On each recursion, we pick a parent p 


from X which primary successor is x, not yet ordered, 
and not yet in the loop. The function then return 
PickStartingPoint(p). 


Algorithm 2 PickStartingPoint(x, loop) 

for all p 6 BMap{x).parents do 
if p 6 loop then return x; 
bp = BMap(p); 

if bp.pSucc = X and bp.order = -1 then 
loop = loop u {p}; 
return PickStartingPoint(p, loop) 
return order; 


• Trace Successors 

This function is also a recursive function with an argu¬ 
ment of block X. It starts by assigning the current order 
o to X then increment o by 1. Then it does recursive 
call to TraceSuccessors giving one successor of 
X which is not yet ordered as the argument (giving 
priority to the primary successor of x if there is one). 


Algorithm 3 TraceSuccessors(x, order) 

BMap{x).order = order; 
if BMap{x).psucc + -1 then 
pSucc = BMap(x).pSucc; 

if BMap{pSucc).order = -1 then return 

TraceSuccessors{pSucc, order + 1); 
for all s e BMap{x).succs do 

if BMap{pSucc).order = -1 then return 

TraceSuccessors{s, order + 1); 
return order; 















E. Output DEX Instructions f Output) 

Since the translation phase already translated the JVM 
instruction and ordered the block, this phase basically just 
output the instructions in order of the block. Nevertheless, 
there are some housekeeping to do alongside producing output 
of instructions. 


• Remember the program counter for the first instruction 
in the block within DEX program. This is mainly 
useful for fixing up the branching target later on. 


Add gotos to the successor when needed for each of 
the block that is not ending in branch instruction like 
goto or if. The main reason to do this is to maintain 
the successor relation in the case where the next block 
in order is not the expected block. More specifically. 


this is step here is in order to satisfy the property B.l 
• Instantiate the return block. 


• Reading the list of DEX instructions and fix up the 
target of jump instructions. 

• Collecting information about exception handlers. It 
is done by sweeping through the block in ordered 
fashion, inspecting the exception handlers associ¬ 
ated with each block. We assume that the variable 
DEXHandler is a global variable that store the 
information about exception handler in the DEX byte¬ 
code. The function newHandler(cS', cE, hPC, t) 
will create a new handler (for DEX) with cS as the 
start PC, cE as the end PC, hPC as the handler PC, 
and t as the type of exception caught by this new 
handler. 


Algorithm 4 makeHandlerEntry(ci/, c^, ciJ) 

for all handler h € cH do 

hPC = h.handlerPC] 
t = h.catchType; 

DEXHandler = DEXHandler + 

newHandler{cS, cE, hPC, t); 


Algorithm 5 translateExceptionHandlers(&^ocfcs) 

cH = 0; // current handler 
cS H current start PC 
cE // current start PC 
for all block x in order do 

if X. handlers is not empty then 
if cH = x.handlers] then 
cE = x.endPC] 
else if cH + x.handlers then 

makeHandlerEntry{cH, cS, cE); 
cS = x.startPC] 
cE = X.endPC] 
cH = x.handlers] 
makeHandlerEntry{cH, cS, cE); 


Algorithm 6 output 

blocks = ordered blocks 6 BMap] 

Ibl = 0] 1/ label mapping 
out = 0; // list of DEX output 
pc = 0] // DEX program counter 
for all block x in order do 
next = next block in order; 
lbl[x] = pc] 

pc = pc + x.insn.length] 
out = out + x.insn] 
if p.pSucc + next then 
if x.insn.last is ifeq then 
t = x.insn.last.target] 
if f = next then 

out.last = oppositeCondition{x.insn.last)] 

else 

out = out + goto{next)] 

else 

out = out -t goto{next)] 
for all index i in out do 

if out[i] is a jump instruction then 
out[i].target = lbl[out[i].target]] 
translateExceptionHandlers{blocks)] 


The only information that are needed to produce the 
information about exception handlers in DEX is the 
basic blocks contained in BMap. The procedure 
translateExceptionHandlers (Algorithmic take 
these basic blocks blocks and make use the proce¬ 
dure makeHandlerEntry to create the exception 
handlers in DEX. 

A note about the last make entry is that the algorithm 
will leave one set of handlers hanging at the end of 
loop, therefore we need to make that set of handlers 
into entry in the DEX exception handlers. 

Eor simplicity, we overload the length of instructions list to 
also mean the total length of instructions contained in the list. 
The operator + here is also taken to mean list append operation. 
The function oppositeCondition takes an ifeq(r, f) and 
returns its opposite ifneq(r, f). Einally, we assume that the 
target of jump instruction can be accessed using the field 
target, e.g. ifeq(r,f).target = t. The details of the steps 
in this phase is contained in Algorithmic 


The full translation scheme from JVM to DEX can be seen 
in table [II] 












JVM 

DEX 

Original Transfer Rule 

Related DEX Transfer Rule 

Push 

Const 

P[z] = Pushu 

P[i] = Const(r, n) 

se, i i-Norm gf se{i) :: st 

se, i i-Norm rf => rf © {r <5e(f)} 

Pop 

None 

P[i] = Pop 

i st ^ st 

None 

Load 

Move 

P[i^ = Loada: 

P[i] = Move(r, Ts) 

se, i st =5- (se(i) u ka{x)^ :: st 

se, i i-Norm rt => vt ® {v (- 56 ( 2 ) u rf(rs))} 

Store 

Move 

P[i'\ = Storea: k u se( 2 ) < ka{x) 

P[i] = Move(r, Ts) 

— ku 

ka kr, se, i l-Norm ^ ^ 

se, i i-Norm rt => rt ® {r se{i) u rt{rs)} 

Binop 

Binop 

P[i] = Binop 

P[i] = Binop(r, ra,rb) 

se, i i-Norm a r. b y. st => {se{i) u a u b) r. st 

se, i i-Norm rf => ri © {r (- 56 ( 2 ) u rf(ra) u rt{rb))} 

Swap 

Move 

P[i] = Swap 

P[i] = Move(r, Ts) 

i ki :: k 2 •• st =5- ^2 ” ” st 

se, i l-Norm rt => Vt ® {r LI 

Goto 

Goto 

P[i] = Goto t 

i st ^ st 

P[i] = Goto t 

i rt ^ rt 

*) Not directly translated 

Ifeq 

Ifeq 

Ifneq 

P[i] = ifeqt \/j e region(z),A: < se{j ) 

P[i] = ifeq(r, i) V/ e region( 2 ), se(i) u ri(r) < se(/ ) 

reigon, se, i i-Norm ^ g^ ^ liftfc(sf) 

Ifeq may be translated into Ifneq on certain condition 

region, se, i i-Norm ^ 

P[f] = ifneq(r, t) \/j' e region(z), se{i) u rt{r) < se{j') 
region, se, i i-Norm ^ 

New 

New 

P[i] = newC 

P[i] = new(r, c) 

se, i i-Norm g^ se(z) :: st 

se, i i-Norm rt => rt ® {v <5e(f)} 

Getfield 

Iget 

P[f] = getfield/ fc e <5 V/e region(z, Norm), fe < se(j) 

P[i] = iget(r, Tq, /) rt{ro) e <5 

V/ e region(f. Norm), rt{ro) < se{j) 

ft, region, se, i k w st ^ liftk((fc U ft(/) u se(z)) :: si) 

P[ 2 ] = getfield/ k^S V/e region(f, np), A: < se(j) 
Handler(z, np) = t 

ft, se, i ri =5- ri © {r 1 -^ rt{ro) U ft(/) u se(i)} 

P[i] = iget(r, Tq, /) rt{ro) e S 

V/ e region( 2 , np), rt{ro) < se{j) Handler( 2 , np) = t 

ft, region, se,f i-"p k :: st ^ {ku se{i)) :: e 

P[ 2 ] = getfield/ fc e <S V/e region(f, np), A: < se(/) 

Handler(f , np) t fe<fcy.[np] 

ft, se, i i-"P rt => ka ® {ex 1 -^ ri(ro) u se(i)} 

P[f] = iget(r, To,/) rf(ro) € <S se(f) u rf(ro) < fcr.[np] 

V/ e region( 2 , np), rt{ro) < se{j) Handler( 2 , np) = t 

ft, region, se, i i-”p k y. st ^ 

~ ~ 

ft, ka kr,se,i i-“P rt => 

Putfield 

Iput 

P[i] = putfield/ kh < ft(/) k\ u se(z) u A :2 < ft(/) 
fci e k 2 ^ S V/e region(z, Norm), A :2 < se(/) 

P[i] = iput(rs , To,/) kh<ft{f) rt{ro) ^ S rt{rs) ^ 
rt{ro) u se{i) u rt{rs) < ft(/) 

V/ e region( 2 . Norm), rf(ro) < se{j) 

— fet _ 

ft, A;a ^ kr, region, se, i i-Norm .. :: st => liftk 2 (^0 

P[i] = putfield/ ki u se(i) u A ;2 < ft(/) Handler( 2 , np) = t 

ki e k 2 ^ S V/ e region(i,np), k 2 < se{j) 

k L _ 

ft, ka ^ kr, se, i l-Norm ^ 

P[i] = iput(rs , To, /) kh<ft{f) rt{ro)^S rt{rs)^S^^^ 
rt{ro) u se(i) u rt{rs) < ft(/) Handler( 2 , np) = t 

V/ e region(f, np), rt{ro) < se{j) 

ft, ka kr, region, se, i i-“p ki :: ^2 ” st ^ {k2 u se(i)) :: e 

P[i] = putfield/ ki u se(z) u A :2 < ft(/) Handler(z, np) t 
ki ^ ^2 e <5 V/ e region( 2 , np), ^2 < se(j) A ;2 < ^^r[rLp] 

~ ~ 

ft, ka -*■ k-r, se, i i-^P rt => ka® {ex 1 -^ rt{ro) u 5e(2)} 

P[i] = iput(rs , To, /) kh<ft{f) rt{ro) ^ S rt{rs) ^ 
rt{ro) u se(z) u rt{rs) < ft(/) Handler(f, np) t 

V/ e region( 2 , np), rt{ro) < se{j) se{i) u rt{ro) < ^^^[np] 

~ ~ 

ft, ka -* k-r, region, se, i i-“p k\ :: k 2 :: st ^ 

kh ~ 

ft, ka kr, se,i i-“P rt => 




JVM 

DEX 

Original Typing Rule 

Related DEX Typing Rule 

Newarray 

Newarray 

P[z] = newarrayt fc e 

P[i] = newarray(r, , t) rt(rj)e<S 

i f. .. ^ fc[at(i)] :: st 

^ ,_Norm ^ 0 ^ rt(rj)[at(2)]} 



P[i] = arraylength \/j e region(z, Norm), fe < se{j) 

kiS fco 6 

P[z] = arraylength(r, Ta) fc[fcc] =) k^S 
kc e Vj e region(2. Norm), k < se(ji) 



region, se, i k[kc] :: st =>■ liftkC^ ” st) 

region, se, i \-f^orm. rt ^ rt ® {r fc} 

Arraylength 

Arraylength 

P[i] = arraylength Vj e region(t, np), k < se{j) 
k ^ S kc ^ ^ext Handler(2, np) = t 

P[z] = arraylength(r,Ta) k[kc] = rt{ra) fc e <S 
kc e 4$®^^ \/j e region(z, np), k < se(j') 

Handler(2, np) = t 

region, se, i i-"p k[kc] :: st ^ (fc u se(i)) :: e 

region, se, i i-^p rt ^ ka ® {ex ku se{i)} 



P[i] = arraylength \/j e region(t, np), k < se{j) 
k ^ S kc ^ ^ext Handler(2, np) t k < /^^-[np] 

P[z] = arraylength(r,Ta) k[kc] = rt{ra) fc e <S 
kc e 4$®^^ Vji e region(z, np), k < se(j') 

Handler(z, np) t se(t) u fc < fca [np] 



ka ^ kr, region, se, i k\kc] - st ^ 

ka -*■ kr, region, se, i \-^p rt ^ 



P[i] = arrayload ki,k2 ^ S kc ^ ^ext 

Vj e region(2, Norm)fe2 < se(jf) 

P[i] = aget(r, ra,ri) k[kc] = rt{ra) kc e 5*^^^ 

k,rt{ri) ^ S Vji e region(z. Norm ),k < se{j) 



ka -*■ kr, region, se,i n k2[kc] :: st ^ 

liftk2 (((^1 L-i ^2) fcc) - st) 

^ region, se, 2 1- rt ^ 

rt © {r 1-^ {{k u rt(ri)) ^c)} 

Arrayload 

Aget 

P[i] = arrayload ki,k2 ^ S kc ^ ^ext 

Vj e region(2, np)A:2 < se{j) Handler(z, np) = t 

P[i] = aget(r, r^, r^) k[kc] = rt(ra) kc e 5*^^^ 
k, rt(ri) e <S Vj e region(2, np), k < se{j) 
Handler(2, np) = t 

ka -*■ kr, region, se,i i-“p ki :: k2[kc] 2 st ^ (^2 LJ se(z)) :: e 

region, se, i i-^p rt ^ ka ® {ex ku se{i)} 



P[i] = arrayload ki,k2 ^ S kc ^ ^ext ^ /^^[np] 

Vj e region(i, np)fc2 < se{j) Handler(t, np) f 

P[i] = aget(r, r^, r^) k[kc] = rt{ra) kc e 5®^^ 
k, rt(ri) e <S Vj e region(t, np), k < se{j) 
Handler(i, np) f se{i) u k < fc,.[np] 



ka -*■ kr, region, se, i i-'^p k\ :: k2[kc'\ - st ^ 

ka -*■ kr, region, se, i \-^p rt ^ 



P[i] = arraystore ki,kc ^ ^2^ ^3 ^ *5 

((^2 LI ks) fci) kc Vj e region(z. Norm), k2 < se(j) 

P[t] = aput(rs, ra, ri) k[kc] = rt{ra) fc,rt(ri)e<S 
{{k u rt(r^)) pt(rs)) kc kc, rt(rs) e 5®’^* 

\/j e region(i. Norm), k < se{i) 



ka -*■ kr, region, se, i n :: k^lkc] :: st =>■ lift^^ 

ka -*■ kr, region, se, i i-Norm ^ 

Arraystore 

Aput 

P[i] = arraystore ki,kc ^ ^ext 

((^2 LI fcs) fci) ^^"^^ fcc k 2 ,k^^S 

Handler(2, np) = t Vj- e region(z, np), ^2 < se{j) 

P[t] = aput(rs, ra, ri) k[kc] = rt{ra) fc,rt(ri)e<S 
((fc u rt(ri)) rt(rs)) kc kc, rt(rs) e 5®’^* 

Vj e region(i, np) , k < se{i) Handler(i, np) = t 

ka ^ kr, region, se, i 1-^^ fei :: ^2 :: fc3[fcc] l st ^ (^2 U se(t)) :: e 

region, se, i i-'^p rt ^ ka ® {ex 1-^ fc u se(i)} 



P[i] = arraystore ki,kf. ^ ^ext k2, k^ e 5 
((^2 Li k^) ki) kc Vj e region(t, np) , ^2 < se(j) 

Handler(i, np) t ^2 < fer[Lip] 

P[t] = aput(rs, ra, ri) k[kc] = rt{ra) fc,rt(ri)e<S 
{{k u rt(ri)) rt(rs)) kc kc, rt(rs) e 5®^* 

Vj e region(i, np ), k < se{i) Handler(i, np) = t 

se{i) u fe < fey.[np] 



ka kr, region, se, i i-”p ki :: ^2 :: k^[kc] 2 st ^ 

ka -*■ fer^egion, se, i i-^p rt ^ 


Move 

and 

Goto 

or 

Return 

P[z] = return se{i) u k < kr 

P[i] = Move(ro, rg) 

Return 

- _ 

ka -*■ kr, se,i \- k st ^ 

se, t 1- rt ^ rt © {r 1-^ (se(z) u rt(rs))} 

P[i] = goto(t) 

2 1- rt ^ rt 

P[i] = return(rs) se(t) u rt(rs) < kr 

kh ~ 

ka -* kr, se,i \- rt ^ 




JVM 

DEX 

Original Typing Rule 

Related DEX Typing Rule 



= invokemiD length(sti) = nbArguments(m/Z)) 

^ - ^a[0] ^ [O’ length(sti) - l]sii[i] < k'^[i + 1] 

ku kh ^ se(i) < k^ fee = |_|{fc^[e] 1 e e excAnalysis(miD)} 

~ ^'h f 

= invoke (n,m,p) r^/[rt(p[0])] =-> fc^ 

rt(p[0]) u fe;, u se{i) < k'^ o<j<nrt(p[j]) < k'a[j] 

fee = 1 _|{fe^[€] [ e e excAnalysis(m )} 



^mj [fc] = k'^ ^ k^ \/ j e region(i, Norm), fc u fee < se{j) 

Vj e region(2, Norm), ^^(^[ 0 ]) u fee < s€{j) 



r, region, se, ka -> k^^ i sti :: k :: st2 => 

• i" 7 Norm , 

i , region, se, ka -*■ kr, i ^ rt ^ 



liftkuke((^r LJ ^ LJ se{i)) :: st2) 

rt © {ret k'.^[n] u rt(p[0]) u se(z)} 



Pmii] = invokemiD length(sti) = nbArguments(m/Z)) 




^ - ^a[0] ^ [0- length(sii) - l]sii[i] < k'^[i + 1] 

fc u fc/i u se{i) < kj^ e e excAnalysis(miD) u {np} 

= invoke (n,m,p) r,^/[rt(p[0])] =-> fe^ 

rt(p[0]) u fe;, u se{i) < k'^ o<j<nrt{p[j]) < k'^[j] 



[fc] = Vj e region('i, e),ku ke < se{j) 

e e excAnalysis(m ) u {np}} Handler(i, e) = t 

Invoke 

Invoke 

Handler(i, e) = t 

Vj e region(2, e), r’t(p[0]) u fe^[e] < se{j) 

g _ 

r, region, se.,ka -*■ kr^i ^ sti v. k y. st2 ^ {ku k'^[e]) :: e 

- e 

r, region, se, ka -* kr ,i rt ^ 




ka © {ex 1-^ k'^[e] u sec(p[0])} 



Pm{.i'\ = invokemiD length(sti) = nbArguments(m/Z)) 

^ - ^a[0] ^ [0- length(sii) - l]sii[i] < k'^[i + 1] 

fc u u se(i) <k^ e e excAnalysis(miD) u {np} 

- ^'h / 

Pm\}\ = invoke {n,m,p) F.^/[sec(p[0])] =k'^ ^ k.^ 

rt(p[ 0 ]) u fch u se{i) < k'^ Vo<j<„ri(p[i]) < k'^[j] 
e e excAnalysis(m ) u {np}} Handler(2, e) f 



^'h 

Fth-jd ~ ^'a ^ region(2, e), fe u fee ^ s^{j) 

Vj e region(2, e), ‘rt(p[0]) u fey,[e] < se{j) 



Handler(z, e) t feu se(2) u < kr[e] 

rt(p[0]) u se{i) u k'^le] < kr[e] 



- _ g 

r, region, se, ka -* k^, i sti :: fe :: st2 ^ 

- 

r, region, se, ka -* kr, i rt ^ 


Moveresult 


Pm\_‘i\ = nioveresult(r) 

i rt rt ® {r ^ rt{ret)} 


TABLE II: Translation Table 


Appendix B 
Proof of Lemmas 

A. Proofs that Translation Preserves SOAP Satisfiability 

We first start this section with proofs of lemmas that are 
omitted in the paper due to space requirement. 

Lemma B.l. Let P be a JVM program and /’[a] = InSa and 
P[b] = Insb are two of its instructions at program points a 
and b (both are non-invoke instructions). Let Ua > 0 be the 
number of instructions translated from InSa- If a fi 

then either 

wmm 

or 

and 

in |P]. 

Proof: To prove this lemma, we first unfold the definition 
of compilation. Lfsing the information that a b, there are 
several possible cases to output the block depending whether 
what instruction is I ns a and where a and b are located. Either: 

• [[&J] are placed directly after [[aj] and [[aJJ [n - 1] is 

sequential instruction; 


In this case, appealing to the definition of successor 
relation this trivially holds as the first case. 

• [[/nsajl ends in a sequential instruction and will have 
a goto instruction appended that points to [[1[6J1[0]]1; 
Again appealing to the definition of successor relation 
this trivially holds as the second case, where 
PDEx[(TW[n- 1]| + 1)] = goto(^l&|[0]|). 

• |[/nsaj|[n-- 1] is a branching instruction and b is one 
of its child, and [[&J] is placed directly after [[aJ] or is 
pointed to by the branching instruction; 

Either case, using the definition of successor relation 
to establish that we are in the first case. 

• [[JnSaJl [n-1] is a branching instruction and b is one of 
its child, nevertheless [[5J] is not placed directly after 
[[aJ] nor is pointed to by the branching instruction; 

In this case, according to the Output phase, a goto 
instruction will be appended in ([[[[aJ] [n-1]]] + 1) and 
thus we are in the second case. Use the definition of 
successor relation to conclude the proof. 


Lemma B.2. Let P be a JVM program and U[a] = InSa and 
P[b] = InSb are two of its instructions at program points a and 
b where b is the address of the first instruction in the exception 
handler h for a throwing exception r. Let e be the index to 




the instructions within [[aj] that throws exception. If a b, 
then ^nd mm 

Proof: Trivial based on the unfolding definition of the 
compiler, where there is a block containing sole instruction 
moveexception, which will be pointed by the exception 
handler in DEX, between possibly throwing instruction and 
its handler for particular exception class t. The proof is then 
concluded by successor relation in DEX. ■ 

Lemma B.3. Let P be a JVM program and P^a] = invoke 
and P\b\ = Insj, are two of its instructions at program points 
a and b. If a b, then [[l[aj][0]]l i-^Norm [[[[aj][l]]] and 

wmm 


Proof: This is trivial based on the unfolding dehnition 
of the compiler since the primary successor of [[liaj][0]]l is 
[[[[aJ][1]]1, where [[T*]![[[l[aj| [I]]]] = moveresult, and the 
primary successor of [[l[aj][l]]l is [O]]]. The proof is then 
concluded by the dehnition of successor relation in DEX. ■ 

Lemma B.4. Let P be a JVM program and P[a] = Ins a 
and P[b] = Insb are two of its instructions at program points 
a and b. Suppose Insj, is translated to an empty sequence 
(e.g. Insb is pop or goto). Let s be the first in the successor 
chain of b such that [[P[s]Jj is non-empty (we can justify this 
successor chain as instruction that cause branching will never 
be translated into empty sequence). If b, then either 

M[n-i]| TW[o]| 

or 

I and 


Proof: We use induction on the length of successor’s 
chain. In the base case where the length is 0, we can use 
Lemma ED to establish that this lemma holds. Eor the case 
where the length is n + 1, there are two possibilities for the 
last instruction in the chain ; 


• the successor is the next instruction 

In this case using the dehnition of successor relation 
we know that it will be in the hrst case. 

• the successor is not the next instruction Since there 
will be a goto appended, it will fall to the second 
case. Using the successor relation we know that the 
latter property holds. 


then use IH to conclude. I 

Lemma (VII. 1 1 . SOAP properties are preserved in the trans 
lation from JVM to DEX. 


Proof: We do prove by exhaustion, that is if the original 
JVM bytecode satishes SOAP, then the resulting translation to 
DEX instructions will also satisfy each of the property. 

SOAPl. Since the JVM bytecode satishes SOAP, that 
means z is a branching point which will also be 
translated into a sequence of instruction. Denote 
ib as the program point in the sequence and is a 
branching point. Let 1[P[A:]J] be the translation 
of instruction P[k] and fci is the address of 


its hrst instruction (l[T’[fc]J| [0]). Using the hrst 
case in the Lemma Lemma [B721 Lemma [B3] 

and Lemma |B.4| we know that ib fci. In 
the case that k € region(z,T), we know that 
ki € region(zb, t) using Dehnition VII.2 In 
the case that k = jun(z{,,'r), we then will have 


ki = jun(zf,,r) using Dehnition VII.6 


Special cases for the second case of Lemma B.l 


Lemma [B.2| and Lemma B.3 in that they contain 
additional instruction in the lemma. We argue 


that the property still holds using Dehnition VII.3 
Dehnition VII.4 and Dehnition |VII.5| Suppose 
k' is the program point that points to the extra 
instruction, then we have k' e region(zt,, r) from 
the 3 dehnitions we have mentioned. Lollowing 
the argument from before, we can conclude that 
ki 6 region(i, t) or ki = jun(zb, r). 

SOAP2. Let in be the last instruction in |T’[j]]. Denote ib 
as the program point in the sequence |z] and is a 
branching point. Let l[P[fc]J] be the translation of 
instruction P\k] and ki is the address of its hrst 


instruction (l[T’[fc]J|[0]). Using Dehnition VII.2 
we obtain € region(z{,, t). Using the hrst 


case of Lemma m Lemma |B.2| Lemma |B.3 
and Lemma |B.4| we will get that jn ki. 
Now since the JVM bytecode satishes SOAP, 
we know that there are two cases we need to 
take care of and k will fall to one case or the 
other. Ass ume k € region(i, r), that means using 
Dehnition VII.2 we will have ki 6 region(in, t). 


Assume k = jun(z,T), we use Dehnition VII. 6 
and obtain that ki = jun(z„,r). Either way, 
SOAP property is preserved for SOAP2. Similar 
argument as SOAPl to establish the second case 
of Lemma EB and that the property is still 
preserved in the presence of moveresult and 
moveexception. 

SOAP3. Trivial 

SOAP4. Let ki = jun(z,Ti) and ^2 = jun(i,r 2 ) (this may 
be a bit confusing, this program point here refers 
to the program point in JVM bytecode). Let ib 
be the instruction in |z] that branch and ku and 
/c 2 i be the hrst instruction in |T’[A:i]] and |P[A: 2 ]] 
respectively. We proceed by using Dehnition |VII.2| 
and the knowledge that the JVM bytecode satisfy 
SOAP4 to establish that when ku + k 2 i, then 
fell € region(zb,''■ 2 ) or k 2 i e region(z{,,'ri) thus 
the DEX program will also satisfy SOAP4. 

SOAP5. Lor any jun(z, r') such that it is dehned, let pro- 


VII.6 


gram point k = jun(z, r'). Using Dehnition _ 

we have ki = jun(z„,T'). Using Dehnition VII.2 


we know that ki 6 region(z„,r). If we then 
set ki to be such point, where jun(z„,r') and 
jun(z„,T') € region(z„,r) for any r' with 
junction point dehned, the property then holds. 

SOAP6. Is similar to the way proving SOAP5, with the 
addition of simple property where the size of a 
code and its translation is covariant in a sense 
that if an program a has more codes than b, then 
|a] also has more codes than |6]. 






















B. Proof that Translation Preserves Typability 

To prove the typability preservation of the compilation 
processes, we define an intermediate type system closely 
resembles that of DEX, except that the addressing is using 
block addressing. The purpose of this intermediate addressing 
is to know the existence of registers typing to satisfy typability 
and the constraint satisfaction for each instructions. We omit 
the details to avoid more clutters. 

Following monotony lemma is useful in proving the rela¬ 
tion of E between registers typing obtained from compiling 
stack types. 

Lemma B.5 (Monotonicity of Translation). Let rt be a register 
types and Si and S 2 stack types. If we have rt E [[iS'iJj and 

E S 2 , then rt E [[S' 2 i| as well. 

Proof: Trivial based on the dehnition of [[.JJ and the E for 
register types. ■ 

Lemma ( |VII.3| i. For any JVM program P with instruction Ins 
at address i and tag Norm, let the length of [[/nsjj denoted 
by n. Let i?r|jj|[Q] = [[5'iJ]. If according to the transfer rule 
for P[i\ = ins exists st s.t. i Si =► st then 

( VO < j < (n - l).3rf.mj] ^ rt', \ 

\ rt' E j 

and 

3rf.[[iJJ[n- 1] ^ rt,rt E [[sfJJ 

according to the transfer rule(s) of [[frisJJ 


Proof: It is case by case instruction, although for most of 
the instructions they are straigthforward as they only translate 
into one in struction. For the rest of the proof, using dehni- 
VII.7 to say that the translated se([[iJJ) have the same 


tion 


security level as se{i). 


• Store X 

This instruction is also translated as move except that 
the source register is the top of the stack and the target 
register is one of the local variable register. The rt in 
this case will be 

rt = se(liij][0])u 

This rt coincides with the transfer rule for move 
where the target register is a register used to contain 
local variable. Since we know that the x is in the range 
of local variable, we will have that rt E based 
on the definition of E, [[.JJ of flattening a stack. 

• Goto 

This instruction does not get translated just like Pop, 
so this instruction also does not affect the lemma. 

• Ifeq t 

This instruction is translated to conditional branching 
in the DEX instruction. There are two things happened 
to the stack types, one is that the removal of the top 
value of the stack which is justified by the definition 
of E, and then lifting the value of the rest of the stack. 
Since there is no lift involved in DEX, we know that 
this assignment will preserve typability as the registers 
are assigned higher security levels. 

• Binop 

Translated as a DEX instruction for specified binary 
operator with the source taken from the top two values 
from the stack, and then put the resulting value in the 
then would be top of the stack. Let rt in this case 
comes from 

rt ® {r{TSi - 2) se([[ijj[0])u 

- 1)) u (i?%j[o](r(r5. - 2)))} 


• Push 

We appeal directly to both of the transfer rule of Push 
and Const. In Push case, it only appends top of the 
stack with se{i). Let such rt be 


This rt corresponds to the scheme of DEX transfer 
rule for binary operation. Then we will have that rt E 
[[sfJJ where st = se(i) u kg u :: st' and Si = ka ■■ 


kb ■■ st' by Lemma VII.2 


rt = ® {r(rS',) se([[tJJ [0])} 

referring to Const transfer rule. Since Push is trans¬ 
lated into Const(r(TS'i)), where TSi corresponds to 
the top of the stack, we know that [[sfJJ = rt because 
7?71i,iirni = Il5'i|| and the rt we have is the same as 

11.44™ sitirtsM 

• Pop 

In this case, since the instruction does not get trans¬ 
lated, this instruction does not affect the lemma. 

• Load X 

Similar to Push except that the security value pushed 
on top of the stack is se([[ijj[0]) u ka{x). And 
although there are several transfer rules for move, 
there is only one applicable because the source register 
comes from local variable register, and the target 
register is one of the stack space. Using this transfer 
rule, we can trivially show that rt = [[sfJJ where 
st = (se(z) U ka{x)) :: Si and rt = ® 

{r(rS'i) se([[ijj[0]) uAJ'a(x)}, thus rt<= [[sfJJ. 


• Swap 

In dx tool, this instruction is translated into 4 move 
instructions. In this case, such rt is 

rt = i?Tpj|[o] ®{ 

r{TS,) - se( W[0]) u RT^,^[o]{r{TS, - 2)), 
r{TS. + 1) - se(W[l]) u RT^,^^i^{r{TS. - 1)), 
riTS, - 2) - se( W[2]) u RT^,^[^^{r{TS, - 1 )), 
r{TS, - 1) ^ se( W[3]) u RT^,^^s{{r{TS, - 2))} 

justified by applying transfer rule for move 4 times. 
As before, appealing to the definition of E to establish 
that this rt E [[sfJJ where st = kb ■■ ka ■■ st' and Si = 
ka •• kb •• st . 

There’s a slight subtlety here in that the relation might 
not hold due to the presence of se in rt whereas there 
is no such occurrence in st. But on a closer look, we 
know that in the case of swap instruction, the effect of 
se will be nothing. There are two cases to consider; 
o If the value in the operand stacks are already 
there before se is modified. We know that this 






can be the case only when there was a con¬ 
ditional branch before, which also means that 
the operand stacks will be lifted to the level of 
the guard and the level of se is determined by 
this level of the guard as well. So practically, 
they are the same thing 

o If the value in the operand stacks are put after 
se is modified. Based on the transfer rules 
of the instructions that put a value on top of 
the stack, they will lub se with the values, 
therefore another lub with se will have no 
effect. 

For the first property, we have these registers typing 
se(W[0])ui?%j[o](r(m-2))} 

RT^iii[2] = ® {r(rs'i + 1) 

^%J|[3] = -^%J|[2] ® {i"{TSi - 2 )<-> 

se(W[2])ui?rpj[3](r(T5,-l))} 

which satisfy the property. 

New 

The argument that goes for this instruction is exactly 
the same as that of Push, where the rt in this case 
is [[S'iJJ ® {r(rS'0 1 -^ se(|[ijj[0])}. 

Getfield 

In this case, the transfer rule for the translated instruc¬ 
tion coincides with the transfer rule for Getfield. Let 


rt = ® {r{TS, - 1) - se(^[0]) u ft(/)} 

Then we have rt = |[sfJJ which can be trivially shown 
with st = se{i) u ft(/) Si thus giving us rt E |[sfJJ. 


Putfield 

Since the JVM transfer rule for the operation itself 
only removes the top 2 stack, and the transfer rule for 
DEX keep the registers typing, when we have rt = 
[[5^1, then by the definition of E we’ll have rt E [[sfj] 
since Si = ko ■■ ky :: st. As before, the registers that 
is not contained in the stack will by definition satisfy 


the E by Lemma VIL2 


Ne war ray 

Similar to the argument of load, we have 


= ®{r(TS'i-1) 1 -^ 


which coincides with [[stj] where st = {kuki)u^^^kc " 
st' and Si = ki k[kc] st' except for lub with 
se{i). The similar reasoning with Swap where lub 
with se{i) in this case will have no effect. 

• Arraystore 

Similar argument with putfield where the JVM in¬ 
struction remove top of the stack and DEX instruction 
preserves the registers typing for rt. Thus appealing 
to the definition of E we have that rt E [[sfJJ. 

• Invoke 

This instruction itself yield 1 or 2 instructions depend¬ 
ing whether the function returns a value or not. Since 
the assumption for JVM type system is that functions 
always return a value, the translation will be that 
invoke and moveresult except that moveresult 

k'h ^ 

will always be in the region Norm. Let -!► fc' be the 
policy for method invoked. Type system wise, there 
will be 3 different cases for this instruction, normal 
execution, caught, and uncaught exception. Eor this 
lemma, the only one applicable is normal execution 
since it is the one tagged with Norm. There will be 
2 resulting instructions since it will also contain the 
instruction moveresult. Let sti be the stack contain¬ 
ing the function’s arguments, t be the top of the stack 
after popping the function arguments from the stack 
and the object reference t = locN + (length(5'i) - 
length(sfi) - 1), where locN is the number of local 
variables. Let k be the security level of object refer¬ 
enced and fee = U{fcr[6] I e € excAnalysis (toid)- 
Since the method can also throw an exception, we have 
to also include the lub of security level for possible 
exceptions, denoted by ke. In this case, such rt can 
be 


^%j|[o] ® { ret>-^ (fc;[n] use([[ij][0])), 
rt ^ (4[n] use(l[tjl[l]))} 

and by definition of E we will have that rt E [[stJJ, 
where st = liftk|jke((^r[’^] LJ se(i)) :: st 2 ) and Si = 
sti :: k :: st2. With that form of rt in mind, then the 
registers typing for can be 

RT^im ^ {ret (4N '-'se(liijj[0])) 

coming from the the transfer rule of invoke in DEX. 


, rt = [[sfj], where st = k[at{i)] :: st',Si = k :: st', 
which will give us rt E [[stjj. 

Arraylength 

Let klkc] = i?T|u||roi(r(TS'i-l)) = S'i[0]. In this case 

rt . fiTpiIO] ®1) » . lij .hen we wil] 

have rt =][stj] where st = k :: st' and Si = k[kc] st' 
which will give us rt E [[stjj. 

Arrayload 

Let k[kc] = i?rpj|[o](r(TS'i-2)) = S'i[l]. In this case 

rt =i?rpj|[o] ® {r{TS^ -2)>-^ 

(se(i) u fc u RT^i^io]{r{TS, - 1))) u®’"* k^} 


• Throw 

This lemma will never apply to Throw since if the 
exception is caught, then the successor will be in the 
tag r + Norm, but if the exception is uncaught then 
the instruction is a return point. 


Lemma ( |VII.4| l. For any JVM program P with instruction 
Ins at address i and tag t + Norm with exception handler 
at address i^. Let the length of [[/nsj] until the instruction 
that throw exception r denoted by n. Let (6e, 0) = [[tejj be 
the address of the handler for that particular exception. If 





according to the transfer rule for Ins iv-'^ Si ^ st, then 

( VO < j < (n - ^ rt\ \ 

[ rt' g RT^^[j+i] ) 

and 

3rt. pJJ [n - 1] ^ rt, rt E RT(^be,o) 

and 

3rt.{he,0) RT(^be,o) rt,rt E |[stJJ 

according to the transfer rule(s) of first n instruction in [[/nsj] 
and moveexception. 

Proof: Case by case possibly throwing instructions: 

• Invoke 

We only need to take care of the case where the 
exception is caught, as uncaught exception is a return 
point therefore there is no successor. In this case, 
n = 1 as the instruction that may throw is the 
invoke itself, therefore the first property trivially 
holds (moveexception can’t possibly throw an ex¬ 
ception). Let locN in this case be the number of local 
variables, and e be the exception thrown. Let k be the 
security level of object referenced. In this case, the 
last rt will take the form 

rt = {fca, ex {ku k'^[e]),r{locN) i-^ (fc u fc' [e])} 

Again with this rt we will have rt E [[sfJJ, where 
st = (fcu fc'[e]) :: e. Such rt is obtained from the 
transfer rule for invoke where an exception of tag r 
is thrown, and the transfer rule for moveexception. 
Then we have the registers typing for (&e,0) as 

RT(be,o) = {ka,ex^ {ku9^[e])} 

which fulfills the second property (transfer rule from 
invoke) and the last property, which when joined with 
the transfer mle for moveexception will give us the 
rt that we want. 

• Throw 

The argument follows that of Invoke for the caught 
and uncaught exception. For uncaught exception, there 
is nothing to prove here as there is no resulting st. 
For caught exception, let k be the security level of the 
exception and locN be the number of local variable. 
Such rt can be 

rt = {ka,ex^^ (/cuse([[jjj[0])), 
rflocN) (fc u se(|[zjj[0]))} 

and it will make the relation rt E |[sfj] holds, where 
st={k\J se{i)) :: e . This rt comes from the transfer 
rules for throw and moveexception combined. 
Registers typing for (6e,0) takes the form of 

RT(^be,o){ka,ex ^ (A:use(|[ij)[0])} 


security environment. The will also come from the 
transfer rule of each respective instruction throwing 
a null pointer exception combined with the mle for 
moveexcept ion. 


Lemma ( |VII.5| l. Let ins be instruction at address i, i j, st. 
Si and Sj be stack types such that i i- 5^ =>■ st, st E Sj. Let n 
be the length Let i?Tpj|[o] = Us'd’ ^'^LJIlo] = li-S'iJJ 

and rt is obtained from the transfer rules involved in [[insJJ. 
Then rt E i?r[|^jj|[o]. 


Proof: Using Lemma VIL3 and Lemma VII.4 to establish 


that we have rt E |sf]. Then we conclude by using Lemma B.5 


to establish that rt E because st E Sj. 


Lemma ( |VII.6| l. Let Ins be instruction at program point i. 
Si its corresponding stack types, and let i?T[|^ij|[o] = [[S'iJJ. 
If P[i\ satisfy the typing constraint for Ins with the stack 
type Si, then e j] will olso satisfy the 

typing constraints for all instructions in [[/nsj] with the initial 
registers typing RT^q^oy 


Proof: We do this by case by case instruction: 


• Push 

This instruction is translated into Const which does 
not have any constraints. 

• Pop: does not get translated. 

• Load X 

This instraction is translated into Move which does 
not have any constraints. 

• Store X 

This instraction is translated into Move which does 
not have any constraints. 

• Goto: does not get translated 


Ifeq t 

This instruction will get translated to ifeq instruction 
where the condition is based on top of the stack 
{TSi - 1). There is only one constraint of the form 
V/ 6 region(i,Norm),rf(r(rS'i - 1)) <se{j'), and 
we know that in the JVM bytecode the constraint Vj' 6 
region(i,Norm), fc < se{j') is fulfilled. Based on the 
definition of [[.jj, we will have k = rt[r{TSi - 1)). 
Thus we only need to prove that the difference in 
region will still preserve the constraint satisfaction. We 
do this by proof by contradiction. Suppose there exists 
such instruction at address {bj,j) € region([[zJ] [n]) 
such that k ^ se{bj,j). But according to defini¬ 
tion |VII.2| such instruction will come from an instruc¬ 
tion at address i' s.t. i' e regio n(i) thus it will satisfy 
k < se{i'). By definition VII.7 se{bj,j) = se(z'), thus 
we will have k < se{bj, j). A plain contradiction. 


which will give us the final rt that we want after the 
transfer rale for moveexception 

• Other possibly throwing instraction 

Essentially they are the same as that of throw 
where the security level that we are concerned with 
is the security level of the object lub-ed with its 


• Binop 

This instruction is translated into Binop or 
BinopConst both of which does not have any con¬ 
straints. 

• Swap 

Trivially holds as well because all the 4 move in- 












stmctions translated from swap do not have any 
constraints. 

New 

Trivially holds as the New does not have any con¬ 
straints. 

Getfield 

There are different sets of constraints depending on 
whether the instruction executes normally, throw a 
caught exception, or throw an uncaught exception. 

In the case of Getfield executing normally, there are 
only two constraints that we need to take care, one is 
that rt{ro) 6 S and Vj 6 region(i,Norm),rf(ro) < 
se{j). The first constraint is trivial, since we already 
have that in JVM the constraint k e S is satisfied, 
where Si = k " st for some stack type st. We 
know that based on the definition of we have 
rt{ro) = k, therefore we can conclude that rt{ro) ^ S. 
The second constraint follows similar argument to the 
satisfaction of region constraint in Ifeq. 

In the case of Getfield is throwing an exception, 
we then know that based on the compilation scheme, 
depending on whether the exception is caught or not, 
the same thing will apply to the translated instruction 
iget, i.e. if Getfield has a handler for np, so does 
iget and if Getfield does not have a handler for 
np, iget does not either. Thus we only need to take 
care of one more constraint in that if this instruction 
does throw an uncaught exception, then it will satisfy 
rt{ro) < fcr[np]. This constraint is also trivially holds 
as the policy is translated directly, i.e. A:r[np] is 
the same both in JVM type system and DEX type 
system, and that rt{ro) = k. Since JVM typing satisfy 
k < fcr[np], then so does DEX typing. 

Putfield 

To prove the constraint satisfaction for this instruction 
we appeal to the translation scheme and the definition 
of [[.JJ. We know from the translation scheme that 
the resulting instruction is iput(r(r5'i - l),r{TSi - 
2),/), so the top of the stack (TSi - 1) corresponds 
to Tg and the second to top of the stack (TSi - 2) 
corresponds to To- Erom the JVM transfer rule, we 
know that the security level of S'i[0] (denoted by 
ki) is in the set of 5®’^* and the security level of 
S'i[l] is in the set of S. Thus we know then know 
that the constraints rt{ro) e S and rt{rs) € 5®’^* 
are fulfilled since we have rt{TSi - 1) = ^^[O] and 
rf(T^,-2) = ^,[l]. 

Now for constraints kh < ft(/) and, {rt{ro) u 
se{i)) u®’^* rt{rs) < ft(/) we know that the policies 
are translated directly, thus the constraint kh < ft(/) 
trivially holds. Eor the other constraint, we know that 
ki = rt{rs), k 2 = rt{ro), and se stays the same, there¬ 
fore the constraint (rf(ro)use(i))u®’^*rf(rs) < ft(/) 
is also satisfied because (^2 u se(i)) u®’'* ki < ft(/) 
is assumed to be satisfied. Lastly, for the rest of the 
constraints refer to the proof in Getfield as they 
are essentially the same (the constraint for region, 
handler’s existence / non-existence, and constraint 
against kr on uncaught exception). 


• Newarray 

Trivially holds as the instruction Newarray does not 
have any constraints. 

• Arraylength 

We first deal with the constraints k e S and kc 6 5®’'*. 
Erom the definition of [[.J], we know that rt{ra) = 
k[kc]- Since JVM typing satisfies these constraints, it 
follows that DEX typing also satisfies this constraints. 
Eor the rest of the constraints refer to the proof in 
Getfield as they are essentially the same (the con¬ 
straint for region, handler’s existence / non-existence, 
and constraint against kr on uncaught exception). 

• Arrayload 

We first deal with the constraints k,rt{ri) e S and 
kc 6 5®’^*. Erom the definition of [[.J], we know that 
ft{ra) = k 2 \kc\ and rt{ri) = ki. Since we know that 
JVM typing satisfies all the constraint, we know that 
rt{ri) 6 S since ki e S, k e S since k2 e S, and 
kc 6 5®’^* since in JVM typing kc e 5®’'*. Eor the rest 
of the constraints refer to the proof in Getfield as 
they are essentially the same (the constraint for region, 
handler’s existence / non-existence, and constraint 
against kr on uncaught exception). 

• Arraystore 

Similar to that of Putfield, where rt{rs) = ki, 
rtin) = k2, and kslkc] = rt{ra) = k'[k'c\. k2,kz 6 S 
gives us k',rt{ri) € S and ki,kc 6 5®’®* gives us 
k'c,rt{rs) 6 5°’®*. In this setting as well, it is easy 
to show that DEX typing satisfies {{k' u rt{ri)) u®’®* 
rt{rs)) <®’®* k'c because JVM typing satisfies ((^2 u 
fca) u®’'* ki) <®’®* kc- Eor the rest of the constraints 
refer to the proof in Getfield as they are essentially 
the same (the constraint for region, handler’s exis¬ 
tence / non-existence, and constraint against kr on 
uncaught exception). 

• Invokevirtual 

There will be 3 different cases for this instruction, 
the first case is when method invocation executes nor¬ 
mally. According to the translation scheme, the object 
reference will be put in p[0] and the rest of parameters 
are arranged to match the arguments to the method 
call. This way, we will have the correspondence that 
rt{p[0]) = k, and Si e [0,length(sfi) - + 

1] = sfi[z]. Since the policies and se are translated 
directly, we will have rf(p[0]) uu se(i) < k'f^ since 
we know that the original JVM instruction satisfy 
kukhUse{i) < k'f^. We also know that rf(p[0]) < fc^[0] 
since k < fca[0]. Similar argument applies to the rest 
of parameters to the method call to establish that 
Si 6 [1,length(sfi) - l]._p[*] < k'g^[i] that in turn 
will give us VO < t < n.rt{p[i]) < k'^[i]. Eor the 
last constraint, we know that excAnalysis also gets 
translated directly, thus yielding the same kc for both 
JVM and DEX. Eollowing the argument of Getfield 
for the region constraint, we only need to make sure 
that rf(p[0]) u kc = k u kg which is the case in 
our setting. Therefore, we will have that constraint 
Vj 6 region(f,Norm).rf(p[0]) u ke < se{j) is 
satisfied. 



The second case is when method invocation thrown 
a caught exception. Basically the same arguments 
as that of normal execution, except that the region 
condition is based upon particular exception Vj € 
region(i,e). rf(p[0]) u fc'[e] < se{j). Since the 
policy stays the same, JVM instruction satisfy this 
constraint will imply that the DEX instruction will 
also satisfy the constraint. Since now the method is 
throwing an exception, we also need to make sure 
that it is within the possible thrown exception defined 
in excAnalysis. Again as the class stays the same 
and that excAnalysis is the same, the satisfaction of 
e € excAnalysis(miD) u {np} in JVM side implies 
the satisfaction of e e excAnalysis(m') u {np} in 
DEX side. 

The last case is when method invocation thrown an 
uncaught exception. Same argument as the caught 
exception with the addition that escaping exception 
are contained within the method’s policy. Since we 
have kuse{i) uA{.[e] < kr[e] in the JVM side, it will 
also imply that rf(p[0]) u se{i) u fc{[e] < fcr[e] in the 
DEX side since rf(p[0]) = k and everything else is 
the same. 

Actually there is a possibility that there is addition 
of moveresult and/or moveexception, except that 
the target of this instruction will be in the stack space, 
therefore there will be no constraint involved to satisfy. 

• Throw 

Similar arguments to that of Invokevirtual ad¬ 
dressing the similar form of the constraints. In the 
case of caught exception case, the constraint e € 
classAnalysis(j) u (np) is satisfied because, as be¬ 
fore, classAnalysis and classes (e) are the same. So, 
if JVM program satisfy the constraint the translated 
DEX program will also satisfy it. The same with 
Vj € region}*, e)r/(r) < se{j) since rt{r) = k. 

The case where exception is uncaught is the same as 
the caught case with addition that the security level of 
thrown exception must be contained within method’s 
policy. In this case, we already have rt{r) < kr[e] 
since rt{r) = k and policies stay the same. 


This lemma states that a typable JVM program (block wise 
and within blocks) will translate into typable DEX program. 


Lemma (VII.7 1 . Let P be a JVM program such that 


1 -^ j.3st.i h- Si 
Then [[PJJ will be 


st 


and 


st £ Si 


1) for all blocks bi,bj s.t. bi i->- bj, 3rtb. s.t. RTsbi =>* 
rtb,rtb E RTsbj; and 

2) Vbi,i,j € bi. s.t. {bi,i) {bi,j).3rt. s.t. {bi,i) \- 
RT{bi,i) rt,rt E RT^bij) 

where 


RTsm = 15,1 

with 

1*JJ = (^*,0) 

RTsb, = 15,JJ 

with 

W = (6J,0), 

RTib^,^) = 15,^1 

when 

1*1 = (&*,*) 

RTib^,j) = 15, 

when 

II 


Proof: Eor the first property, they are mainly proved using 
Lemma IVII.5I because we know that if a DEX instruction is 
at the end of a block, it is the last instruction in its translated 
JVM instruction, except for invoke and throwing instructions. 
Based on Lemma VII.5 we have that rt E RT(^bj,o)’ where 
RRibjfl) = [[SjJ]. iSmce by definition rtb is such rt and 
RTsbj = RT(^bj,o)’ the property holds. Eor invoke we use 
the first case of Lemma VII.3 and for throwing instructions 
we use the first case of Lemma IVII.4I 


Eor the second property, it is only possible if the DEX 
instruction at address i is non-invoke and non-throwing in¬ 
struction. There are two possible cases here, whether i and j 
comes from the same JVM instruction or not. If i and j comes 
from the same JVM instruction, then we use the first case of 
Lemma [Vll.3| Otherwise, we use Lemma [VII.5| 


Before we proceed to the proof of Lemma fVII.S we define 
a property which is satisfied after the ordering and output 
phase. 


Property B.l. For any block whose next order is not its 
primary successor, there are two possible cases. If the ending 
instruction is not ifeq, then there will be a goto instruction 
appended after the output of that particular block. If the ending 
instruction is ifeq, check whether the next order is in fact the 
second branch. If it is the second branch, then we need to 
“swap” the ifeq instruction into ifneq instruction. Otherwise 
appends goto to the primary successor block. 


Lemma (VII. 81 . Let [[PJ] be a typable DEX blocks resulted 
from translation of JVM instruction still in the block form, i.e. 


[[Pj] = TransIate(TraceParentChiId(StartBIock(P))) 


Given the ordering scheme to output the block contained in 
PickOrder, if the starting block starts with flag 0 (P(o,o) = OJ 
then the output |P] is also typable. 


Proof: The proof of this lemma is straightforward based 
on the definition of the property and typability. Assuming that 
initially we have the blocks already typable, then what’s left 
is in ensuring that this successor relation is preserved in the 
output as well. Since the output is based on the ordering, and 
the property ensures that for any ordering, all the block will 
have correct successor, then the typability of the program is 
preserved. 

To flesh out the proof, we go for each possible ending of 
a block and its program output. 

• Sequential instruction 

There are two possible cases, the first case is that 
the successor block is the next block in order. Let 
bi indicate the current block and bj the successor 
block in question. Let in be the last instruction in 
bi, then we know that 3rt.RT(^bi,i„) rt,rt E RTsbj 
where RTsbj will be the registers typing for the next 
instruction (in another word RT(^bj,o))- Therefore, the 
typability property trivially holds. 

The second case is that the successor block is not the 
next block in order. According to step performed in 
the Output phase, the property |B.1| will be satisfied. 
Thus there will be a goto appended after instructions 




















in the block output targetting the successor block. Let 
such block be bi and the successor block bj. Let 
in be the last instruction in bi. From the definition 
of typability, we know that if bj is the next block 
to output, then => rt,rt £ RTsbj. 

Now with additional goto in the horizon, we appeal 
to the transfer rule to establish that this instruction 
does not need to modify the registers typing, i.e. 
3Tt.{bi.fin') ^ ^ + 7 1 ) ^ 

RT(bt,i„+i) rt,rt £ RTsbj where RT(^bi,z„+i) = rt. 

ifeq 

There are three possible cases here, the first case is 
that the next block to output is its primary successor. 
It is trivial as the relationship is preserved in that the 
next block to output is the primary successor. 

The next case is that the next block to output is 
its secondary successor. We switch the instruction to 
its complementary, i.e. ifneq. Let bi be the current 
block, bj be the primary successor (which is directly 
placed after this block), and bk the other successor. 
Let in be the index to the last instruction in bi. If bi 
ends with ifneq, then we know that it is originally 
from the instruction ifeq and the blocks are typable, 
therefore we have that for the two successors of bi the 
following relation holds: Irti.in => rti,rti £ RTstj 
and 3rt2.in rt 2 ,rt 2 E RTsbk, which defines the 
typability for the output instructions. 

The last case is when the next block to output is 
not its successor. The argument is the same as the 
sequential instruction one, where we know that adding 
goto can maintain the registers typing thus preserving 
the typability by fixing the successor relationship. 

For the secondary successor (target of branching), we 
know that there is a step in the output that handles the 
branch addressing to maintain the successor relations. 

invoke, yet the next block to output is not 
moveresult 

Although superficially this seems like a possibility, 
the fact that moveresult is added corresponding 
to a unique invoke renders the case impossible. If 
moveresult is not yet ordered, we know that it will 
be the next to output based on the ordering scheme. 
This is the only way that a moveresult can be given 
an order, so it is impossible to order a moveresult 
before ordering its unique invoke. 


The operator ® denotes the function where p ® {r u} 
means a new function p' such that Vi e dom(p)\{r}.p'(i) = 
p{i) and p'{r) = v. The operator ® is overloaded to also mean 
the update of a field on an object, or update on a heap. 

For method invocation, program comes equipped with a 
set M. of method names, and for each method m there are 
associated list of instructions Pm. Each method is identified 
by method identifier toid which can refer to several methods in 
the case of overriding. Therefore we also need to know which 
class this method is invoked from, which can be identified by 
auxilliary function lookupp which returns the precise method 
to be executed based on the method identifier and class. 

To handle exception, program will also comes equipped 
with two parameters classAualysis and excAualysis. 
classAualysis contains information on possible classes of 
exception of a program point, and excAualysis contains 
possible escaping exception of a method. 

There is also additional partial function for method m 
Haudlerm : W xC W which gives the handler address 
for a given program point and exception. Given a program 
point i and an exception thrown c, if HaudlermC*, c) = t then 
the control will be transferred to program point t, if the handler 
is undefined (noted Haudlerm(*, c) t) then the exception is 
uncaught in method m. 

The next figure is the full version of figure in 
section The full typing judgement takes the form of 
F, ft, regiou, s^n, se, i st => st' where F is the table of 
method policies, ft is the global policy for fields, regiou is 
the CDR information for the current method, sgn is the policy 

for the cuiTent method taking the form of ka kr, se is the 
security environment, i is the current program point, st is the 
stack typing for the current instruction, and st' is the stack 
typing after the instruction is executed. 

As in the main paper, we may not write the full notation 
whenever it is clear from the context. In the table of operational 
semantics, we may drop the subscript TO,Norm from e.g. 
we may write instead of -^m.Norm to mean the same thing. 
In the table of transfer rules, we may drop the superscript of 
tag from and write i- instead. The same case applies to 
the typing judgement, we may write i st ^ st' instead of 

F, ft, regiou, ka kr, se, i sf => st'. 


Appendix C 

Full JVM Operational Semantics and Transfer 
Rules 

The following figure is the full operational semantics 
for JVM in section The function fresh : Heap ^ £ is an 
allocator function that given a heap returns the location for that 
object. The function default : C ^ O returns for each class 
a default object of that class. For every field of that default 
object, the value will be 0 if the field is numeric type, and 
null if the field is of object type. Similarly default Array : 
N X 7j ^ (N ^ V). The relation which defines transition 
between state is State x (State + V x Heap). 


Pm [i] = goto j _ Pm[i\ = swap _ Pm[i\ = goto 3 

(z, p, os) '^m,Norm (ji Pi Os) (z, p, Z’l " V2 " Os) '^m,Norm li Pi ^2 " '^1 " Os) (z, p, 05) '^m,Norm (ji Pi ^^ 5 ) 

Pm[i] = ifeqj n + 0 Pm[*] = ifeqj n = 0 Pm [*] = store a; x 6 dom(p) 

(z, p, rz :: os) -^m.Norm (* + li Pi os) (z, p, n :: os) '^m,Norm (j, Pi os) (z, p, r :: os) -^m.Norm (z + li p ® {x x}, os) 

Pm[z] = load X -Pm[*] = binop op n 2 op ni = n Pm[*] = return 

(z, P, os) -^m.Norm (* + li Pi p{x) " Os) (z, p, ZZi :: n2 ” os) -^m.Norm (z + li Pi ZZ 2 OS) (z, p, ZZ :: os) -^m.Norm Z”, h 

Pm[z] = new C ? = fresh(ft,) Pm[z] = getfield / ? € doni(ft,) f e dom{h{l)) 

{i,p,os,h) ^ (z + 1, Pi ? " os, ft. ® 1-^ default(C)}) (z, p, I :: os, ft) '^m,Norm {i+^,P,h{l).f " os, ft) 

.Prri[*] = getfield / /' = fresh(ft) Pm[z] = push n 

(z, p, rzzzft :: os, ft) -^m.np RuntimeExcHandling(ft, np, z, p) (z, p, os) -^m.Norm (* + li Pi zz :: os) 

.Pm[z] = putfleld / I 6 dom(ft) /€doni(ft(^)) Pm[z] = pop 

(z,p,V :: I :: OS,h) -^m.Norm (* + liPiOS, ft® h{l) ® {/ x}}) {i,P,V" os) -^m.Norm (z+ l,p,OS) 

Pm[z] = putfield / /' = fresh(ft) Pm[*] = return 

(z, p, X :: null os, ft) '^m,np RuntinieExcHandling(ft, P, np, z, p) (z, p, x :: os) '^rn,Norm x, ft 

Pm[*] = newarray t I = fresh(ft) rz > 0 
(z, p, n :: os, ft) '^m,Norm (* + li Pi ^ •• os, ft ® {I (rz, defaultArray(rz, t), z)}) 

Pm[*] = arraylength ^ 6 dom(ft) 

{i,p,l ■■■■ os,h) '^m,Norm (* + 1, p, ft(0-length os, ft) 

Pm[*] = nrrnylength P = fresh(ft) 

(z, p, null ■■■■ os, ft) -^m.np RuntinieExcHandling(ft, P, np, z, p) 

Pm[z] = arrayload I € doni(ft) 0 < j < ft(l). length 
(z,p,j :: I :: os,h) -^m.Norm (z + 1, p, ft(/) [j] :: os, ft) 

Pm [*] = arrayload P = fresh(ft) 

{i,p,j ■■ null ■■■■ os,h) '^m,np RuntinieExcHandling(ft, P,np,z,p) 

Pm[z] = arraystore I 6 doni(ft) 0 < j < ft(l).length 
(z, p, X :: j :: I :: os, ft) -^m.Norm (z + 1, p, os, ft ® h{l) ® {j x}}) 

Pm[z] = arraystore P = fresh(ft) 

(z, p, X :: j :: null " os, ft) -^m.np RuntinieExcHandling(ft, P, np, i, p) 

Prrz[z] = invoke ttzid zzz' = lookupp(rrziD,class(ft(/))) I 6 doni(ft) 
length(osi) = nbArgunients(rrziD) (li {tftzs l,x <-* osi}, e, ft) ^m, v, ft' 

(z, p, osi :: I :: 0S2, ft) -^m.Norm (z + 1, p, X :: 0S2, ft') 

Pm[z] = invoke rzziD ni' = lookupp(rrziD, class(ft(l))) (l,{tftzs l,x <-* osi},e,h) -^m' {1')^^' 

I 6 doni(ft) Handlerm(ft e) =t e = class(ft'(P)) e € excAnalysis(r7ZiD) 

(z, p, osi :: I :: 0 S 2 , ft) -^m.e (t, p, P " e, ft') 

Pm[*] = invoke rrziD P = fresh(ft) 

{i,p,osi ■■■■ null ■■■■ 0S2,ft) -^rn.np RuntimeExcHandling(ft, np,z,p) 





Pm[i\ = invoke mm 'm = lookupp(TOiD, class(/i(^))) {l,{this l,x <-* osi},e,h) {l'),h' 
I e dom.{h) e = class{h' (I')) Handlerm(*, e) t e € excAnalysis(TOiD) 

{i, p, osi :: I :: 0S2, h) {I'), h' 

Pm[i] = throw r = fresh(/i) 

(i, p, null ■■■■ os, h) -^m.np RuntimeExcHandling(/i, np, i, p) 

-fm[*]= throw I e dom{h) e = class{h{l)) Handlerm(*, e) = t e e classAnalysis(m,i) 

{i, p, I:: os, h) -^ra,e (t, p, I ■■■ e, h) 

Pm[i] = throw I € dom(/i) e = class(/i(/)) Handlerm(i, e) f e e classAnalysis(m, i) 

{i,P,l ■■■ OS,h) -^ra,e ( 1 ), h 

with RuntimeExcHandling : Heap x CxC x W x (X ^ V) ^ State + (£ x Heap) defined as 


Runt imeExcHandling ( h, l',C,i,p) 


{{t, p, V :: e,h® {V ^ default (C')})if Handlerfji(i, C) =t 
!(/'), ft, ® {/' default(C')} if Handleri„(*, C) f 


Fig. 7: Full JVM Operational Semantic 


Pm[i] = load X 


^m[*] = store a; se{i) u k < ka{x) 


P-m[i] = swap 


se, i\- st^ {ka{x) U se{i)) :: st se,i\- k:: st ^ st i\- ki :: ^2 " st ^ " fti " st 

Fm[*] = ifeqj Vj' 6 region(ft Norm), ft < se(j') Pm[*] = goto j Pm[*] = return se{i) u k < kr[n] 


region, se,i\- k ■■ st => liftk(st) 

Pm [*] = binop op 

se,i H ki :: ^2 " st => (fci U ^2 U se(i)) :: st 

_ Pm [»] = new C _ 

F, ft, ka ^ kr, region, se, ie- st ^ se{i) :: st 


it- st ^ st 
Pm[i] = push n 


ka kr, se,i t- k :: st = 
Pm [*] = pop 


se, it- st ^ se(i) " st it- k" st ^ st 

Pm [t] = newarray t k e S 

^ kh ^ 

r, ft, ka ftr, region, se, i i-Norm fc[at(z)] st 


Pm[i] = getfield / k e S Vj e region(z. Norm), k < se{j) 
r,ft, ka ^ kr, region, se,i i-Norm j, .. gf ^ liftk(((fc u se(z)) ft(/)) " st) 

[t] = getfield / keS Vj e region(z,np),ft < se(j) Handler(z,np) = t 
r,ft, ka kr, region, se,i i-"p ft :: st => (ft U se(i)) :: e 


= getfield / keS Vj e region(z, np), ft < se(j) Handler(z,np) f ft<ftr[np] 
F, ft, ka ^ Ay, region, se, i i-"p k st ^ 

Pm[i] = putReld f (se(i) u ft 2 ) fti <ft(/) fci e 5®’'* ft 2 e 5 kh<ft{f) 

Vj € region(i,Norm), ft 2 < se{j) 

k h 

F, ft, ka ftr, region, se, i l-Norm .. .. gf ^ liftka (st) 





P„[i] =putfield / {se{i)uk2)u^^^ ki<{t{f) fci e fca € 5 

Vj 6 region(i, np), k2 < se{j) Handler(z, np) = t 

r, ft, ka kr, region, se,i ki :: ^2 " st => (^2 U se(i)) :: e 

P„[z] =putfield / (se(z)u/c2)u®’'‘A:i<ft(/) fci € ^2 e 5 

Vj 6 region(z,np), fc < se(j) Handler(z, np) t ^2 < fcr[np] 
r, ft, ka ^ fcr, region, se, z i-"p ki :: A:2 " st => 

Pm[*] = arraylength k € S kc € 5 ™*^ Vj 6 region(z,Norm), A: < se(j) 
r, ft, ka fcr, region, se, i i-Norm ;; gi ^ liftk(A: " st) 

Pm[*] = arraylength keS kc^S'^^^ Vj 6 region(z,np),A: < se(j) Handler(z,np) = A 
r, ft, ka^ kr, region, se, i h"p A:[A;c] " sA => (A: u se(z)) :: e 

Pm [z] = arraylength keS kc ^ Vj € region(z,np),fc < se(j) Handler(z, np) t fc<A:r[np] 

r, ft, ka kr, region, se, i i-"p k[kc] ■■ st => 

Pm [z] = arrayload ki,k2^S Vj € region(z,Norm),A:2 < se(j) 

r,ft, ka'^ kr, region, se,i ki :: A:2[A;c] " st liftk2(((A:i u A:2) u®’'* kc) ■■ st) 

Pm [z] = arrayload ki,k2^S kc^S^^^ Vj e region(z, np), ^2 < se(j) Handler(z, np) = A 
r,ft,A;o -> fcr, region, se, z (-"p ki ■■ A;2[A:c] " st => (^2 u se(z)) :: e 

Pm[z] = arrayload ki,k2^S kc^S^"^^ Vj e region(z,np), A:2 < se(j) Handler(z,np) f A:2<A:r[np] 

r,ft,A:o -i" A:r,region, se,z i-"p ki :: fc2[A:c] - st => 

Pm[z] = arraystore {{k2 u ks) ki) kc k2,k-ieS ki,kc^S°^^ 

Vj 6 region(z. Norm), A:2 < se(j) 

kh 

r,ft,A;a ^ A;^, region, se,z i-Norm .. :: A:3[A:c] " st ^ liftk2(sA) 

Pm[z] = arraystore {{k2 u ks) ki) kc k2,k-ieS ki,kc^S°^^ 

Vj € region(z, np), k2 < se{j) Handler(z, np) = A 

r, ft, ka Ajr, region, se,i h"p ki :: k 2 ■■ A: 3 [fcc] •• st => {k 2 U se(i)) :: e 

Pm[z] = arraystore ((^2 u A;3) A:i) A;c k2,k-ieS ki,kc^S^^^ 

Vj 6 region(z, np), ^2 < se(j) Handler(z,np) t A:2 < A;r[np] 

r, ft, ka A:^, region, se,z i-"p A:i :: k2 ■■ A:3[A;c] " st => 

^ ^'h ^ 

Pm[*] = invoke TOiD length(sAi) = nbArgunients(TOiD) Tmin[k] = k'a ^ k'r 
Vz € [0, length(sAi) - l].sAi[z] < A)*^[z + 1] k < ka[0] k u kh u se{i) < k'f^ 

A;e = l_|{A:^[e] | e € excAnalysis(miD)} Vj e region(z. Norm), A; u fee < se(j) 

r,ft, ka ^ Av, region, se,z i-Norm .. j... g^^ ^ liftfeufce ((fcr[^] u se(i)) :: SA2)) 




Pm[*] = invoke TOiD length(sti) = nbArguments(miD) r^iD [fc] = 

Vz € [0, length(sti) - l].sti[j] <+ 1] k < k'^[0] k u k^ u se{i) < k'f^ 
e 6 excAnalysis(TOiD) u {np} Handler(z, e) = t € region(z, e), fc u fc^[e] < se{j) 

r,ft,A:a -*■ fcr, region, se,z i-® sti :: k :: st2 => (fcu /c' [e]) :: e 

Pm[i] = invoke toid length(sti) = nbArgunients(miD) rmiD[^] = K 
Vz € [0, length(sii) - l].sti[z] </c*q[z + 1] k < k'^[0] k u kh u se{i) < k'f^ fc u se(z) u A'[e] < Av[e] 
e € excAnalysis(TOiD) u {np} Handler(z,e) t Vj € region(z, e),/c u fc}[e] < se{j) 

r, ft, ka^ kr, region, se, z i-'= sti :: k :: st2 

^rn[*] = throw e € classAnalysis(z) u (np) Vj € region(z, e), k < se{j) Handler(z, e) =t 
r, ft, ka -*• fcr, region, se, z i-® A::: st ^ (fc U se(z)) :: e 

Pm[z] = throw e 6 classAnalysis(z) u (np) k < kr[e] Vj e region(z, e),k < se{j) Handler(z, e) t 

r, ft, fco -*■ fcr, region, se, k" st ^ 


Fig. 8: JVM Transfer Rule 


Appendix D 

Full DEX Operational Semantics and Transfer 
Rules 

The following figure]^ is the full operational semantics for 
DEX in section ||V] It is similar to that of JVM, with several 
differences, e.g. the state in DEX does not have operand stack 
but its functionality is covered by the registers (local variables) 
p. The function fresh : Heap ^ £ is an allocator function that 
given a heap returns the location for that object. The function 
defanlt : C ^ O returns for each class a default object of 
that class. Eor every field of that default object, the value will 
be 0 if the field is numeric type, and null if the field is of 
object type. Similarly default Array : N x T}? -*■ (N ^ V). 
The relation which defines transition between state is 
State X (State + V x Heap). 

The operator ® denotes the function where p ® (r u) 
means a new function p’ such that Vz 6 dom(p)\{r}.p'(z) = 
p{i) and p'{r) = v. The operator ® is overloaded to also mean 
the update of a field on an object, or update on a heap. 

To handle exception, program will also comes equipped 
with two parameters classAnalysis and excAnalysis. 
classAnalysis contains information on possible classes of 
exception of a program point, and excAnalysis contains 
possible escaping exception of a method. 

There is also additional partial function for method m 
Handlerm ^ 'P'P x C PP which gives the handler address 
for a given program point and exception. Given a program 
point z and an exception thrown c, if Handlerin(f, c) = t then 
the control will be transferred to program point t, if the handler 
is undefined (noted Handlerm(*, c) t) then the exception is 
uncaught in method m. 


The next figure 
section IIVI The ful 
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IS 


the full version of figure in 
typing judgement takes the form of 
r, ft, region, sgn, se, z rt =► rt' where F is the table of 
method policies, ft is the global policy for fields, region is 
the CDR information for the current method, sgn is the policy 

for the current method taking the form of ka kr, se is the 
security environment, z is the current program point, rt is the 
register typing for the current instruction, rt' is the register 
typing after the instruction is executed. 


As in the main paper, we may not write the full notation 
whenever it is clear from the context. In the table of operational 
semantics, we may drop the subscript 77i,Norm from e.g. 
we may write instead of -^m.Norm to mean the same thing. 
In the table of transfer rules, we may drop the superscript of 
tag from and write i- instead. The same case applies to 
the typing judgement, we may write i rt => rt' instead of 

r, ft, region, ka ^ kr, se, it-'' rt ^ rt'. 








Pm[*] = const(r, w) r 6 dom(p) Pm[i] = move(r,rs) r € dom(/9) Pm[*] = goto(i) 

(i,p,/l) -^m^Norm (* + 1 ,P® {r (l,/ 0 ,/i) -^m.Norm (*+ 1 ,P® {r / 9 (rs)},/l) {i,P,h) {t,p,h) 

P[i]m = ifeq(r, j) p(r) = 0 Pm[z] = ifeq(r,t) /9(r) ^ 0 P[i]^ = return(rs) 6 dom(/9) 

(i, /), /l) '^m,Norm P^ h) (z, /), /l) '^m,Norm "*■ I5 P^ h) (z, /?, /z) '^m,Norm pi^’^s')^ h 

Pjn[i] = hinop{op,r,ra,rb) r,ra,n e dom{p) n = p{ra) op pin) 

(i, p, ft,) '^m,Norm (i + 1, p ® {r n}, ft) 

= iget(r,ro,/) p(ro) 6 dom(ft) / 6 dom(ft(p(ro))) _ P^[z] = new(r,c) / = fresh(ft) _ 

(z,p, ft) -^m.Norm (i+ l,p® {r ft(p(ro) )./}, ft) (*,P, ft) (z + 1 , p ® {r /}, ft ® {Z default(c)}) 

Pm[»] = iget(r,ro,/) p(ro) = zzzzi? /' = fresh(ft) Pm[z] = iput(rs,ro,/) p{ro)=null ?'= fresh(ft) 

(z, p, ft) -^m^np RuntimeExcHandling(ft, V, np, z, p) (z, p, ft) -^n^np RuntimeExcHandling(ft, np, z, p) 

Pm[z] = iput(rs,ro,/) p(ro) 6 dom(ft) / 6 dom(ft(p(ro))) 

(i,p,h) '^„,Norm (*+ l,p,os, ft® {p(ro) h{p{ro)) ® {/ '^ p(’"s)}}) 

Pm[z] = newarray(r,r;,t) I = fresh(ft) p(r;) > 0 
{i,p,h) {i + 1 , p 9 {r 1 } ,h 9 {I <-* (p(n),defaultArray(p(n),<),z)}) 

P„t[z] = arraylength(r,ra) p(ra) 6 dom(ft) 

(z,p,ft) -^m.Norm (z+ l,p® {r ft(p(ra)).length, ft}) 

Pm[z] = arraylength(r, Ta) p{ra) = null ft = fresh(ft) 

(z, p, ft) -^m.np RuntimeExcHandling(ft, ft, np,z,p) 

Pm[z] = aget(r,ra,ri) p(ra) 6 dom(ft) 0 < p(r,) < ft(p(ra)).length 
(z, p, ft) -^m.Norm (z + 1 , p ® {r ^(ft(^a) ) [p(ri) ] }, ft) 

Pm[z] = aget(r,ra,ri) pjrg) = null ft = fresh(ft) 

(z, p, ft) -^m^np RuntinieExcHandling(ft,ft, np,z,p) 

Pm[z] = aput(rs,ra,ri) p(ra) 6 dom(ft) 0 < p(r,) < ft(p(ra)).length 
(i,p,h) -^m.Norm (* + 1, p, ft ® {p(ra) h{p{ra)) ® {p(ri) p(rs)}}) 

Pm[z] = aput(rs,ra,ri) p{ra) = null /'= fresh(ft) Pm[z] = moveresult(r) r € doni(p) 

(i,p,h) -^m.np RuntimeExcHandling(ft,/',np,z,p) {i,P,h) -^m.Norm (z + l,p® {r p(ret)},ft) 

Pm[z] = invoke(n,m',p) p e doni(p) (1, {5 p), ft)w, ft' 

{i,p,h) -^m.Norm (z + 1, p ® {ret zz), ft') 

Pm[z] = invoke(rz,TO',p) p6doni(p) (1, {5 p), ft)(ft), ft' 

e = class(ft'(ft)) Handlerm(z, e) = t e e excAnalysis(m') 

(i,p,h) (t,p® {eccH^ ft},ft') 

Pm[z] = invoke(n,TO',p) ft = fresh(ft) p(p[0]) = null 
(z, p, ft) -^m^np RuntinieExcHandling(ft,ft, np,z,p) 




Pm[z] = invoke(n,TO',p) pedom{p) {l,{x p},h){l’),h’ 

e = class{h'{I')) Handlerjn(*, e) t e € excAnalysis(TO') 

^rn^e 

Pm[z] = throw(r) /9(r) € dom(/i) e = class(/i(p(r))) Handlerm(z, e) = t e € class Analysis (to, i) 

{i,p,h) (t,p®{ex p{r)},h) 

Pm[*] = throw(r) p(r) € dom(ft,) e = class(/i(p(r))) Handleri„(z, e) t e € classAnalysis(TO,z) 

(i,p,h) '-rm,e {p{r)),h 

Pm[*] = throw(r) I'= fresh(/i) p{r) = null Pm[*] = nioveexception(r) r € dom(p) 

(z, p, h) '^m,np RuntimeExcHandling(/z, I', np, z, p) (z, p, h) -^m.Norm (z + 1, p ® {r p{ex)}, h) 

RuntimeExcHandling : Heap x CxC x VV x (TZ ^ V) ^ State + (£ x Heap) defined as 


Runt imeExcHandling (ft,, l',C,i,p) = 


{t, p ® {ex 1-^ /'}, ft ® {V 1-^ default(C)}) 
(ft), h® {V >-* default(C)} 


if Handlerm(z, C*) = t 
if Handleri„(z, C*) t 


Fig. 9: DEX Operational Semantic 


Pm[i\ = const(r,z;) _ Pm[i\ = new(r,c) _ _ Pm[i\ = move(r,r^) _ 

se, z I- rf => r< ® {r 1 -^ se(z)} se, z i-Norm ^ se(z)} se, z t- rf => rf ® {r {rt{rs) u se m 

Pm[i] = return(r^) se(z) u rf(rg) < _ Pm[i] = binop(op, r, rg, r;,) _ 

^ se,i K rf ^ se,i^rt^rt®{r^ (rt(rj u rt(rb) u se(z))} 

Pm[i] = ifeq(r,f) Vj' e region(z,Norm), se(z) urf(r) < se{j') 
r, ft, fco ^ kr, region, se, i\- rt^rt 
Pm[i\ = ifneq(r,f) Vj' e region(z,Norm),se(z) urf(r) < se{j') 
r, ft, fco ^ kr, region, se, i\- rt^rt 

Pm[*] = iget(r,ro,/) rt{ro) e S Vj e region(z. Norm),rt(ro) < se(j) 
r,ft, ka ^ kr, region, se, i rf => rf ® {r ((^^(^o) u se(z)) ft(/))} 

Pm[f] = iget(r,ro,/) rt{ro) e S Vj € region(z,np), rf(ro) < se(j) Handler(z,np) = f 
r, ft, ka kr, region, se, z i-"p rt^ka® {ex {rt{ro) u se(z))} 

Pm[z] = iget(r,ro,/) rf(ro) e 5 Vj e region(z, np),rf(ro) < se(j) Handler(z,np) f se(z) u rf(ro) < fcr[np] 

r, it,ka ^ Av, region, se, i i-"p rt => 

Pm[f] = iput(r,ro,/) rf(r)€5®’'* rt{ro)^S (rt(ro) u se(z)) u®'"* rf(ro) < ft(/) fc/i < ft(/) 

Vj € region(z,Norm),rf(ro) < se(j) 

r, ft, ka^ kr, region, se, Z l-Norm ^ 





Pm[i] = iput{rs,ro,f) rt(rs) e 5®’'* rt{ro) e S (ri(ro) u se(i)) u®’"* rt(rs) < ft(/) 

Vj € region(i,np),r<(ro) < se{j) Handler(i,np) = t 

r, ft, ka fcr, region, se, i h"p rt^ ka® {ex rt{ro) u se(i)} 

Pm[i] = iput{rs, To, f) rt(rs)6 5®’'* rt(ro) e 5 (rt(ro) u se(i)) u®’"* rt(rs) < ft(/) 

Vj 6 region(i,np), rt(ro) < se(j) Handler(i,np) f se(z) u rt(ro) < fcr[np] 

r, ft, fca ^ kr, region, se, i i-"p rt => 

Pm[i] = newarray(r,r;,t) rt{ri) 6 S rt(r;)[at(i)] < ka{r) 

^ kh ^ 

r, ft, fca ^ kr, region, se, i i-Norm r<(r;) [at(i)]} 

Pm[z] = arraylength(r, Ta) k[kc] = rt{ra) keS kc^S^^^ Vj e region(z,Norm),A: < se(j) 

^ kh ^ 

r, ft, fco ^ kr, region, se, i i-Norm ^ j-f ^ s^j. 

Pm[i] = arraylength(r. To) k[kc\ = rt{ra) keS kc e 5®’"* k < ka{r) 

Vj € region(z, np), fc < se(j) Handler(z,np) = t 

r,ft,fca ^ fcr,region, se, z i-"p rt^ ka® [ex (fcu se(z))} 

Pm[i] = arraylength(r, Xa) k[kc] = rt{ra) keS kc e 5®’"* k < ka{r) 

Vj 6 region(z,np), fc < se(j) Handler(z, np) t se(z) u fc < fca[np] 
r, ft, fca ^ kr, region, se, i i-"p rt => 

Pm[»] = aget(r,ra,ri) k[kc\=rt{ra) k,rt{ri)eS fee e >S®^* Vj e region(z. Norm), fc < se(j) 
r, ft, ka ^ kr, region, se,i i-Norm ^ ((se(z) u fc u rt(ri)') u®’'* fc^)} 

P™[z] = aget(r,ra,ri) fc[fcc] = rt(ra) k,rt{ri)eS fcc 6 5®’"* 

Vj € region(z, np), fc < se(j) Handler(z,np) = t 

^ kh. ^ ^ 

r,ft,fca -!► fcr,region, se, z i-"p rt^ ka® [ex (fcu se(z))} 

Pm[z] = aget(r,ra,rj) k[kc] = rt{ra) k,rt{ri)eS fcc € 5®’'* 

Vj € region(z,np),fc < se(j) Handler(z,np) f se(z) u fc < fcr[np] 

r, ft, fca ^ kr, region, se, z i-"p rt => 

Pm[z] = aput(rs,ra,rj) fc[fcc] = rt(ro) k,rt{ri)eS fcc,rt(rs) € 5®’'* 

((fc u rt{ri)) u®’'* rt{rs)) <®’'* fcc Vj e region(z,Norm), fc < se(j) 

r, ft, ka^ kr, region, se, Z l-Norm ^ 

Pm[z] = aput(rs,ra,rj) fc[fcc] = rt(ra) k,rt{ri)eS fcc,rt(rs) e 5®’"* 

((fc u sec(ri)) u®’^* sec(rs)) <®’'* fcc Vj e region(z, np), fc < se(j) Handler(z, np) = t 

^ kh ^ ^ 

r, ft, ka kr, region, se, z i-"p rt^ka® [ex (fc u se(z))} 

Pm[z] = aput(rs,ra,rj) fc[fcc] = rt(ro) k,rt{ri)eS kc,rt{rs) e 

((fc u rt(ri)) u®’'* r<(rs)) <®’'* fcc Vj e region(z, np), fc < se(j) Handler(z, np) f se(z) u fc < fcc[np] 

r, ft, fcc ^ kr, region, se, z i-"p rt => 




Pm[*] = moveresult(r) 

r, ft, ka ^ kr, region, se, i i-Norm ^ se(z) u rt{ret)} 

Pm[i] = invoke(n, m',p) Tm'[rt{p[0])] = k'^-i k'^ rt{p[0]) u kh u se{i) < k'f^ 'iO < i < n.rt{p[i]) < k'^[i] 

fce = l_J{^r[c] I e 6 excAnalysis(m')} Vj e region(z. Norm), rt(p[0]) u fee ^ se(j) 

r, ft, ka ^ Av, region, se,i rt {rt ® {ret fc^[n] u se(z)})) 

Pm[i{ = invoke(n, w',p) rm'[rt(p[0])] = -> rt(p[0]) u fc/j u se(z) < VO < z < n.rt(p[z]) < fc^[z] 

Handler(z,e) =t e 6 excAnalysis(r7z') u {np} Vj 6 region(z, e),rt(p[0]) u fc^[e] < se{j) 

r, ft, fca fcr,region, se,i i-® rt => fca ® {ex (rt(p[0]) u k'^[e\)} 

Pm[i\ = invoke(n, m',p) rm'[rt(p[0])] = -> rt(p[0]) u fc/i u se(z) </cjj VO < z < rz.rt(p[z]) < fc{,[z] 

rt(p[0]) u se(z) u Ac'[e] < kr[e\ e e excAnalysis(TO') u {np} 

Handler(z,e) f Vj e region(z, e),rt(p[0]) uk{[e{ < se{j) 

r, ft, ka fcr, region, se, rt^ 

-Pm[*] = throw(r) e e classAnalysis(z) u {np} Vj e region(z, e), rt(r) < se(j) Handler(z, e) = t 
r, ft, ka fcr, region, se,i i-'^ rt^ rt® {ex {rt{r) u se(z))} 

Pm\i] = throw(r) e e classAnalysis(z) u {np} Vj e region(z, e),rt(r) < se(j) 

Handler(z, e) f se(z) u rt{r) < kr [e] 

r, ft, ka fcr, region, se, i\-^ rt^ 

Pm[i] = nioveexception(r) 

r,ft, ka kr, region, se, i rt => rt ® {r (rt(ex) u se(z))} 

Fig. 10; DEX Transfer Rule 


Appendix E 
Auxilliary Lemmas 

These lemmas are useful to prove the soundness of DEX 
type system. 

Lemma E.l. Let k e S a security level, for all heap h 6 Heap 
and object /array o e O (or o € A), h <k ft.® {fresh(/z) o) 

Lemma E. 2 . For all heap ft, ftg e Heap, object o e O and 

I = fresh(ft), ft ho implies h® {I o) ho 

Lemma E. 3 . For all heap ft,fto 6 Heap and ft(/) ^ ftobs, 

ft ho implies h® {l*-^ h{l) ® {/ v}} ho 

Lemma E. 4 . For all heap ft, fto e Heap, r € R, p e R V, 
rt 6 (TZ S), p{r) e doni(ft), p(r) is an array, integer 
0 < z < ft(p(r)). length, rt{p{r)) = k[kc\ and kc kohs, 
ft '•^p ho implies ft ® {p(r) h{p{r)) ® {z r}} '^p ho 

Lemma E. 5 . For all heap ft, ft', ftp e Heap, k ^ kobs, ond 
h < 1 , h', h'^p ho implies h' ~p ho 

Lemma E. 6 . If fti ~p ft 2 , if ft = fresh(fti) and ft = 
fresh(ft2) then the following properties hold 


• VC, fti ® {ft 1-^ default^} ~p ft2 

• VC, fti ~p ft2 ® {ft 1-^ default^} 

• VC, fti® {ft 1-^ defaultc} ~p ft2®{/2 default^} 

• 'il,t,i, fti ® {ft (ftdefaultArray(Z,t),z)} ft2 

• yi,t,i, fti '^p ft2 ® {ft 1-^ (/, default Array}/, t),z)} 

• V/,t,z,/',t',z' fti®{/i 1-^ (/, default Array (/,t),z)} 
~p ft2 ® {/2 (/',defaultArray(/',t'),z')} 

Lemma E. 7 . pi ~rti,rt2,0 P2 implies for any register r e pi : 

• either rti(r) = rt2(r), rti(r) < fcobs ond pi{r) ~p 
P2{r) 

• or rti{r) i kohs and rt2{r) i kohs 

Appendix E 

Proof that typable DEXx implies non-intereerence 

In this appendix, we present the soundness of our type 
system for DEX program i.e. typable DEX program implies 
that the program is safe. We also base our proof construction 





on the work Barthe et. al., including the structuring of the 
submachine. In the paper, we present the type system for 
the aggregate of the submachines. In the proof construction, 
we will have 4 submachines: standard instruction without 
modifying the heap (DEXx), object and array instructions 
(DEXq), method invocation (DEX^), and exception mecha¬ 
nism (DEXg). 

There are actually more definitions on indistinguishability 
that would be required to establish that typability implies non¬ 
interference. Before we go to the definition of operand stack 
indistinguishability, there is a definition of high registers : let 
p € {TZ V) be register mapping and rt e {TZ ^ 5 ) be a 
registers typing. 

Several notes here in this submachine, since the execution 
is always expected to return normally, the form of the policy 
for return value only takes the form of instead of kr- There 
is also no need to involve the heap and /? mapping, therefore 
we will drop them from the proofs. 

Definition F.l (State indistinguishability). Two states {i,p) 
and {i',p') are indistinguishable w.r.t. rt,rt' € (TZ S), 
denoted {i,p) ‘ff PP' 

Lemma F.l (Locally Respects). Let {i,pi),{i,p2) e State/ 
be two DEXx states at the same program point i and let two 
registers types rti,rt2 e (TZ S) such that si S2- 

• Let s'i,S2 6 State/ and rt'i,rt2 e (TZ ->■ S) such that 

Si s'l, S2 S2, i ^ rti => rt'i, and i t- =► ^2, 
then s[ 4 - 

• Let ui,U2 6 V such that si Vi, S2 V2, rti =>, 
and i t- =>■, then kr < kohs implies Vi ~ V2- 

Proof: By contradiction. Assume that all the precedent 
are true, but the conclusion is false. That means, is distin¬ 
guishable from s'2, which means that where ps< is 

part of sj and p^/^ are parts of sf This can be the case only if 
the instruction at i is modifying some low values in pi and p2 
to have different values. We will do this by case for possible 
instructions : 

• move(r, Ts). This case is trivial, as the distinguisha- 
bility for pg'^ and p^/^ will depend only on the source 
register. If the source register is low, then since we 
have that pi ~ p2, they have to have the same value 
(pi(fs) = P2(rs)), therefore the value put in r will be 
the same as well. If the source register is high, then the 
target register will have high security level as well (the 
security of both values will be rt(rs) u se(i), where 
rt(rs) ^ kohs), thus preserving the indistinguishability. 

• binop(r, Ta, r/). Eollowing the argument from 
move, the distinguishability for p^/ and p^/^ will 
depend only on the source registers. If source registers 
are low, then since we have that pi ~ p2, they have to 
have the same values (pi(ro) = P2(ra) and pi(rh) = 
P2(rb)), therefore the result of binary operation will 
be the same (no change in indistinguishability). If any 
of the source register is high, then the target register 
will have high security level as well (the security level 
of the resulting value will be rt(ra) u rt(rb) u se(i), 


where rt(ra) i fcobs and/or rt(rb) i kohs), thus 
preserving the indistinguishability. 

• const(r, u). Nothing to prove here, the instruction 
will always give the same value anyway, regardless 
whether the security level of the register to store the 
value is high or low. 

• goto(j). Nothing to prove here, as the instruction 
only modify the program counter. 

• return(rs). This is a slightly different case here than 
before, where we are comparing the results instead of 
the state (ui ~ U2). Again, the reasoning is that to 
have different result and they are distinguishable, we 
need the register from which the value is returned to 
be high (rt(rs) ^ fcobs), but the security level of the 
return value of the method is low (kr < kohs)- But this 
is already taken care of by the transfer rule which state 
rt(rs) < kr- Therefore, a contradiction. 

• ifeq(r,/). A special case where there might be a 
branching thus the states compared are at two different 
program counters. If the register used in comparison 
is low (rt(r) < kohs), we know that the program 
counter will be the same and there will be nothing 
left to prove (ifeq is just modifying program counter). 
If the register is high (rt(r) ^ fcobs), the operational 
semantics tells us that there is no modification to the 
registers. Therefore, register wise these two states are 
indistinguishable. 


Lemma F .2 (High Branching). Let si,S2 e State/ be two 
DEXx states at the same program point i and let two registers 
types rti,rt2 e (TZ ^ S) such that s/ ~£^^rti,rt2 '^2- V 
two states (ii, p'j^), (12, P2) 6 State/ and two registers type 
rt'i,rt2 e (TZ^ S) s.t. ii + 12, si (/i,p'i), S2 {'12, P2), * 
rti rt'i, z I- rt2 =► 'f't'2 then Vj e region(z), se(j) ^ kohs- 

Proof: This is already by definition of the branching 
instruction (ifeq and ifneq). se(i) will be high because r will 
by definition be high. This level can not be low, because if the 
level is low, then the register r is low and by the definition 
of indistinguishability will have to have the same values, and 
therefore will take the same program counter. Since se is high 
for scope of the region, we have Vj 6 region(z), se(j) ^ fcobs- 

■ 

Lemma F .3 (indistinguishablility double monotony), if 
s grpt,S and T £U then s jjjjt 

Lemma F .4 (indistinguishablility single monotony), if 
s t, S' E S" and S is high then s t 

Appendix G 

Proof that typable DEXq implies non-interference 

Indistinguishability between states can be defined with the 
additional definition of heap indistinguishability, so we do not 
need additional indistinguishability definition. In the DEXq 
part, we only need to appropriate the lemmas used to establish 
the proof. 

Definition G.l (State indistinguishability). Two states {i,p, h) 
and {i',p',h') are indistinguishable w.r.t. a partial function 



P e C ^ C, and two registers typing rt, rt' € {JZ S), denoted 
{i,P,h) iff P '^k^,rt,rt' P' ^ ~/3 

hold. 

Lemma G.l (Locally Respects). Let /3 a partial function (3 € 
C C, si,S2 6 Stateo be two DEXq states at the same 
program point i and let two registers types rti,rt2 € (TZ S) 
such that Si ^ 2 - 

• Let Si,S2 6 Stateo and rt[,rt2 6 {TZ S) such that 

51 Si,S2 S2, it- rti =>■ rt'i, and i 1- rt2 =>■ 
then there exists ( 3 ' e C ^ C such that S2 

52 and /3 £ /3'. 

• Let vi,V2 6 V such that Si vi, S2 V2, rti =>, 

and i 1- =>, then kr < kohs implies Vi V 2 . 

Proof: By contradiction. Assume that all the precedent 
are true, but the conclusion is false. That means, s'l is distin¬ 
guishable from S2, which means either p'l -P p'2 or h'l + h'2, 
where p'i,h'i are parts of s'l and P2 j^ 2 parts of s^. 

• assume h'^ + h'2. This can be the case only if the 
instruction at i are iput, newarray, and aput. 

o iput(rs, To, /) can only cause the difference 
by putting different values (pi(rs) + P2{'f’s)) 
with rfi(rs) i fcobs and rt2{ra) i fcobs on a 
field where ft(/) < fcobs- But the transfer rule 
for iput states that the security level of the 
field has to be at least as high as Ts, i.e. sec < 
ft(/) where sec = rti{rs) = rt2{rs). A plain 
contradiction. 

o aput(rs,T q, Ci) can only cause the difference 
by putting different values (pi(rs) + P2{fs)) 
with rfi(rs) i fcobs and rt2{rs) i fcobs on an 
array whose content is low (kc < fcobs, fc[fcc] is 
the security level of the atTay). But the typing 
rule for aput states that the security level of 
the array content has to be at least as high as 
Vs, i.e. sec < kc where sec = rti(rs) = rt2{rs). 
A plain contradiction. 

o newarray(ra,r;,f) can only cause the dif¬ 
ference by creating array of different lengths 
(pi{ri) * P 2 (n)) with rfi(rj i fcobs and 
rt2{rs) i fcobs- But if that’s the case, then 
that means this new array does not have to be 
included in the mapping j 3 ' and therefore the 
heap will stay indistinguishable. A contradic¬ 
tion. 

• assume p'^ + p'2. This can be the case only if the 
instruction at i is modifying some low values in p'l and 
p'2 to have different values. There are only three pos¬ 
sible instructions in this extended submachine which 
can cause p'l + p'2: iget, aget, and arraylength. 
We already have by the assumption that the original 
state is indistinguishable, which means that the heaps 
are indistinguishable as well (hi ~ /i2)- Based on the 
transfer rule we have that the security level of the 
value put in the target register will at least be as high 
as the source. If the security is low, we know from 
the assumption of indistinguishability that the value 
is the same, thus it will maintain registers indistin¬ 
guishability. If the security is high, then the value put 


in the target register will also have high security level, 
maintaining registers indistinguishability. 


Lemma G.2 (High Branching). Let (3 a partial function 
P e C ^ C, si,S2 c Stateo be two DEXq states 
at the same program point i and let two registers types 
rti,rt2 c {TZ ^ S) such that si Let two 

states (ii,P2, (12,P2, ^2) ^ Stateo and two registers 

type rt'i,rt'2 e (TZ S) s.t. ii + 12,si 
■S2 (*2,P2,^2)- If i ^ fti ‘’"i'lA ^ ^^2 T’t'2 then 

Vj 6 region(i),se(j) i kohs 

Appendix H 

Proof that typable DEXc implies security 

Since now the notion of secure program also defined with 
side-effect-safety due to method invocation, we also need to 
establish that typable program implies that it is side-effect-safe. 
We show this by showing the property that all instruction step 
transforms a heap h into a heap h' s.t. h<kf^ h'. 

Lemma H.l. Let {i, p,h),{i', p',h') e Stateo be two states 
s.t. {i,p,h)) '^rn {ifp',h'). Let two registers types rt,rt' 6 

(TZ S) s.t. region, se,fca ^ kr,i rt => rt' and 

P[i] + invoke, then h h' 

Proof: The only instruction that can cause this difference 
is newarray, new, iput, and aput. For creating new objects 
or arrays. Lemma |E. 1 | shows that they still preserve the side- 
effect-safety. For iput, the transfer rule implies kh < ft(/). 
Since there will be no update such that kh i ft(/), h <k^ h' 
holds. ■ 

Lemma H.2. Let {i,p,h) e Stateo be a state, h' e Heap, 
and V € V s.t. {i,p,h) v,h'. Let rt 6 {TZ S) s.t. 

region, se, ka ^ kr,i rt =>, then h <k^ h' 

Proof: This only concerns with return instruction at the 
moment. And it’s clear that return instruction will not modify 
the heap therefore h<kf, h' holds ■ 

Lemma H.3. For all method m in P, let (region^,juUm) 
be a safe CDR for m. Suppose all methods m in P are 
typable with respect to regioUm and to all signatures in 
Policiesr(m). Let {i, p,h), {i', p',h') € Stateo be two states 
s.t. {i,p,h) '•^rn {i',p',h'). Let two registers types rt,rt' 6 

{TZ S) s.t region, se, ka ^ K-, i rt => rt' and 

P[i] = invoke, then h h' 

Proof: Assume that the method called by invoke is toq. 
The instructions contained in m' can be any of the instructions 
in DEX, including another invoke to another method. Since 
we are not dealing with termination / non-termination, we can 
assume that for any instruction invoke called, it will either 
return normally or throws an exception. Therefore, for any 
method mo called by invoke, there can be one or more chain 
of call 

mo mi m„ 

where m m' signify that an instruction in method m calls 
m'. Since the existence of such call chain is assumed, we can 


use induction on the length of the longest call chain. The base 
case would be the length of the chain is 0, which means we 
can just invoke Lemma H.l and Lemma [H. 2 | because all the 


instructions contained in this method mo will fall to either one 
of the two above case. 


The induction step is when we have a chain with length 1 
or more and we want to establish that assuming the property 
holds when the length of call chain is n, then the property also 
holds when the length of call chain is n+ 1 . In this case, we just 
examine possible instructions in mo, and proceed like the base 
case except that there is also a possibility that the instruction 
is invoke on mi. Since the call chain is necessarily shorter 
now mo mi is dropped from the call chain, we know that 
invoke on mi will fulfill side-effect-safety. Since all possible 
instructions are maintaining side-effect-safety, we know that 
this lemma holds. ■ 


Since all typable instructions implies side-effect-safety, 
then we can state the lemma saying that typable program will 
be side-effect-safe. 

Lemma H.4. For all method m in P, let fregionm,junmj 
be a safe CDR for m. Suppose all methods m in P are 
typable with respect to regionm and to all signatures in 
Policiesr(m). Then all method m is side-effect-safe w.r.t. 
the heap effect level of all the policies in Policiesr(m). 


Then, like the previous machine, we need to appropriate 
the unwinding lemmas. The unwinding lemmas for DEXq stay 
the same, and the one for instruction moveresult is straight¬ 
forward. Fortunately, Invoke is not a branching source, so 
we don’t need to appropriate the high branching lemma for 
this instruction (it will be for exception throwing one in the 
subsequent machine). 

Lemma H.5 (Locally Respect Lemma). Let P a program 
and a table of signature T s.t. all of its method m! are non- 
interferent w.r.t. all the policies in Policiesr(m') and side- 
effect-safe w.r.t. the heap effect level of all the policies in 
Policiesr(m'). Let m be a method in P, j 3 € L L a 
partial function, si,S2 6 Statec two DEXc states at the same 
program point i and two registers types rti,rt2 e ( 72 - ^ S) 
s.t. Si '^kahB,rti,rt 2,/3 S2. If there exist two states s'l.s^ e Statec 
and two registers types rt[,rt2 e (P- S) s.t. 

51 '^ra Si ‘^nd r, region, se, ka kr,i\- rti => rf j 

and 

52 '^m' s'2 and r, region, se, ka kr,i rt2 

then there exists j 3 ' e L ^ L s.t. s'j^ rt' rt' /3' s'2 and 


Proof: By contradiction. Assume that all the precedent 
are true, but the conclusion is false. That means, s'l is distin¬ 
guishable from S2, which means either p'^ + p'2 or /ij + h'2, 
where p'i,h'^ are parts of s'j^ and p'2, h'2 are parts of s^. 

• Assume h'l -P h'2. invoke(TO,n,p) can only cause 
the state to be distinguishable if the arguments passed 
to the function have some difference. And since the 
registers are indistinguishable in the initial state, this 
means that those registers with different values are 


registers with security level higher than fcobs (let’s say 
this register x). By the transfer rules of invoke, this 
will imply that the k'^[x] ^ kohs (where 0 < a; < n). 
Now assume that there is an instruction in m using 
the value in x to modify the heap, which can not be 
the case because in DEXo we already proved that the 
transfer rules prohibit any object / array manipulation 
instruction to update the low field / content with high 
value. 

• Assume ps' + pf. invoke only modifies the pseudo¬ 
register ret with the values that will be dependent on 
the security of the return value. Because we know 
that the method invoked is non-interferent and the 
arguments are indistinguishable, therefore we can con¬ 
clude that the result will be indistinguishable as well 
(which will make ret also indistinguishable). As for 
moveresult, we can follow the arguments in move 
(in DEXx), except that the source is now the pseudo¬ 
register ret. 


Appendix I 

Proof that typable DEXp implies security 

Like the one in DEX^, we also need to firstly prove the 
side-effect-safety of a program if it’s typable. Fortunately, this 
proof extends almost directly from the one in DEXc. The 
only difference is that there is a possibility for invoking a 
function which throws an exception and the addition of throw 
instruction. The proof for invoking a function which throws an 
exception is the same as the usual invoke, because we do not 
concern whether the returned value r is in L or in V. The 
one case for throws use the same lemma ED as it differs 
only in the allocation of exception in the heap. The complete 
definition : 

Lemma I.l. Let (i, p, h), {i', p', h') e States be two states s.t. 
{i,p,h) {i',p',h'). Let two registers types rt,rt' e {P 

S) s.t. region, se,fca kr,it- rt ^ rt' and P\i\ + invoke, 
then h h' 


Proof: The only instruction that can cause this difference 
are array / object manipulation instructions that throws a null 
pointer exception. For creating new objects or arrays and 
allocating the space for exception. Lemma E. 1 shows that they 
still preserve the side-effect-safety, throw instruction itself 
does not allocate space for exception, so no modification to 
the heap. ■ 


Lemma 1.2. Let {i,p,h) € Statec be a state, h' e Heap, 
and V e V s.t. {i,p,h) v,h'. Let rt e (P S) s.t. 

region, se, ka J h rf =>, then h h' 


Proof: This can only be one of two cases, either it is 
return instruction or uncaught exception. For return instruc¬ 
tion, it’s clear that it will not modify the heap therefore 
h <kf, h' holds. For uncaught exception, the only difference 
is that we first need to allocate the space on the heap for the 
exception, and again we use lemma E. 1 to conclude that it will 
still make h <k, h' holds ■ 





Lemma 1.3. Let for all method m e P, fregion^, jun^j 
a safe CDR for m. Suppose all methods m e P are typable 
w.r.t. region,^ and to all signatures in Policiesr(TO). Let 
{i, p,h),{i', p',h') € States be two states s.t. {i,p,h) 
{i',p',h'). Let two registers types rt,rt' € (TZ ->• S) s.t. 

region, se, ka -*■ i rt ^ rt' and P[i\ = invoke, then 
h <k^ h' 

Proof: In the case of invoke executing normally, we 
can refer to the proof in Lemma |H. 3 | In the case of caught 
exception, if it is caught then we can follow the same reasoning 
in Lemma |I.l| i. In the case of uncaught exception it will fall 
to Lemma lL 2 l ■ 

Lemma 1.4. Let for all method m e P, fregion^j, jun^j 
a safe CDR for m. Suppose all methods m e P are typable 
w.r.t. region^ and to all signatures in Policiesr(TO). Then 
all method m are side-effect-safe w.r.t. the heap effect level of 
all the policies in Policiesr(TO). 

Proof: We use the dehnition of typable method and 
Lemma [LT| Lemma [TSI and Lemma lO] Given typable method, 
for a derivation 

(^ 0 ; Pt ); ^0 ) To Pi ^ bi) .. . (^ 5 ^) 

there exists RT e W (TZ S) and rti,... € (TZ S) 

s.t. 

io 1 -'^° RTig ^ rti ii RTi^ ^rt 2 ,...in RTi„ => 
Using the lemmas, then we will get 

ho <k^ <hn<h 

which we can use the transitivity of <k^ to conclude that 
ho <k^ h (the dehnition of side-effect-safety). ■ 

Definition 1.1 (High Result). Given {r,h) € (U + L) x Heap 
and an output level kr, the predicate highResultk,.(r, h) is 
defined as : 

kr[n]fkohs v&V fcr[class(h(Z))] ^ hobs Z € dom(h) 
highResultk,.(u, h) highResultk,.(((), h) 

Definition 1.2 (Typable Execution). 


Proof: We do a structural induction on the instruction in 
i. This lemma is only applicable if the instruction at i is either 
a return instruction, or a possibly throwing instruction with 
uncaught exception. 


Return ; the transfer rule has a constraint that kr\n\ 
will be at least as high as se which is high. So by 
dehnition the lemma holds. Since return does not 


modify heaps, we know that h^ 


h' 


Invoke ; the transfer rule where the instruction is 
throwing an uncaught exception e has constraint say¬ 
ing that kr{e] will be at least as high as se, the level 
of exception thrown by the method invoked, and the 
object level on which the method is invoked. We know 
se is high, so by dehnition the lemma holds. Heap 
wise, we know that th e exc eption is newly generated 
so we can use Lemma E .6 to say that hr ~/3 h'. 


• Iget : the transfer rule where the instruction is throw¬ 
ing an uncaught exception np has constraint saying 
that fcr[np] will be at least as high as se and the 
security level of the object. We know se is high, so 
by dehnition the lemma holds. Heap wise, we know 
that the exc eption is newly generated so we can use 
Lemma E .6 to say that hr h'. 


Iput : Same as Iget. 

Aget; the transfer rule where the instruction is throw¬ 
ing an uncaught exception np has constraint saying 
that fcr[np] will be at least as high as se and the 
security level of the array. We know se is high, so 
by dehnition the lemma holds. Heap wise, we know 
that the exc eption is newly generated so we can use 
to say that hr h'. 


Lemma 


E .6 


• Aput : Same as Aget. 

• Array length ; Same as Aget. 

• Throw : the transfer rule has a constraint that for any 
uncaught exception e, kr{e] will be at least as high as 
se which is high. So by dehnition the lemma holds. 
Throw does not modify heap as well, so we have hr ~p 
h'. 


• An execution step {i,p,h) is typable 

w.r.t. RT 6 PP ->• (JZ S) if there exists rt' s.t. 
i RTi => rt' and rt' E RTi^ 

• An execution step (i, p, h) -^rn t b!) is typable w.r.t. 
RT e PP ^ {TZ^ S) ifi ’PTi => 

• An execution sequence Sq Si 

■ ■■Sk '^m Tfc (a b') is typable w.r.t. RT 6 PP (TZ 
S)if: 

o yi ,0 < i < k,Si '^rriTi Si+i is typable w.r.t. 
RT; 

° Sn '^m,T„ (f,b') is typable w.r.t RT. 

Lemma 1.5 (High Security Environment High Result). Let 
(i, p,h),(i', p',h') e Statec, se(i) is high, {i,p,h) '^p 
(i', p',h') i 1-^ and {i, p, h) (r, hr), then highResult(r, hr) 
and hr '^p h'. 


Lemma 1.6 (High Region High Result). Let se be 
high in region(s,T), jun(s,T) is never defined, 
{'io,Po,ho),{i',p',h') 6 Stateo, {io,Po,bo) ^p (i',p',h') 
and there is an execution trace 

(^0; PO 5 ^0 ) ■ {ik: Pk ; ^k ) m,rfc 5 ) 

where (io,Poibo) € region(s,T). Then highResult(r, 
and hr '^p h'. 

Proof: We do induction on the length of the execution. 
Eor the base case where fc is 0 we can use Lemma Ol In the 
induction step, we know that {ik,Pk,bk) is in region(s,T) 
using SOAP 2 and eliminating the case where it is a junction 
point by the assumption that jun(s, r) is never dehned. Since 
we now have shorter execution length, we can apply induction 
hypothesis. Heap wise, we know from the transfer rules that 







field / array update will be bounded by se, thus we have hr 


h' by Lemma E .3 and Lemma E .4 


Lemma 1.7 (High Register Stays). Let {iQ,pQ,ho) e Stateo 
and there is an execution step such that 


(io, Po, ho) ^m,To ■ ■ ■ {ik, Pkyhk) 

and se is high in io,... ,ik, if RTo{r) is high then RTk{r) is 
high. 


Proof: We do induction on the length of execution, and 
we do case analysis on do possible instructions. If the length 
of execution is 0 we have {io,po,ho) {ik,Pk,hk). 

The instruction is not a return point, since it contradicts the 
assumption. If the instruction is an instruction that modify r, 
we know that these instructions will update the register r with 
security level at least as high as se, so the base case holds. 
In the induction step, we show using the same argument as 
the base case that RTi{r) is high, therefore now we can 
invoke induction hypothesis on the trace {ii,pi,hi) 

• ■ ■ (f fc 5 Pk ) h}^) I 

Lemma 1.8 (Changed Register High). Let {io,po,ho) e Stateo 
and there is an execution step such that 

(^01 P0 1 ho ) '^m.TQ ■ • • {ik: Pk ; ) 

and se is high in iq, ..., ik, and the value of r is changed by 
one or more instruction in the execution trace, then RTk{r) 
is high. 

Proof: We do case analysis on where the first change 
might happen [ 1 ] then we do case analysis on all of the 
register modifying instructions change register r to high [ 2 ] 
and invoke Lemma |l^ to claim that they stay high until 
it reaches {ikTPk,hk). All these instructions which modify 
register r will update the register r with security level at least 
as high as se so we already have [ 2 ]. Since we assume that 
there is a change, [ 1 ] trivially holds. ■ 

Lemma 1.9 (Unchanged Register Stays). Let {io,po,ho) e 
Stateo and there is an execution step such that 

(io, Po, ho) ■ ■ ■ {ik, Pk, hk) 

and the value of r is not changed during the execution trace, 
then RTo{r) = RTk{r) and Po{r) = Pk{r). 

Proof: We do induction on the length of execution, and 
we do case analysis on do possible instructions. If the length 
of execution is 0 we have {io,po,ho) {ik,Pk,hk)- 

The instruction is not a return point, since it contradicts the 
assumption. If the instruction is an instruction that modify r, 
we know that it contradicts our assumption. If the instruction 
does not modify r then the base case holds by definition. 
In the induction step, we show using the same argument as 
the base case that RTofr) = RTi{r) and po{r) = pi(r'), 
therefore now we can invoke induction hypothesis on the trace 
{il, Pi, hi) '^rn,Ti ■ • • {ik, Pk, hk) ■ H 

Lemma I.IO (Junction Point Indistinguishable). Let /3 a par¬ 
tial function fS € L ^ L and {io,po,ho),{i'o,p'o,h'o) s Statec 
two DEXg states such that 

{io,Po,ho) '^RTi„,RT,, {i'o, P'o^h'fj 

U Iq 


and io = i'o- 

Suppose that se is high in region regionm(*0i To) and also 
in region regionr„(*o,Tg). Suppose we have a derivation 

{io, Po, ho) ’^m.TQ • • ■ {ik, Pk, hk) (^5 h) 

and suppose this derivation is typable w.r.t. RT. Suppose we 
have a derivation 


(* 0 ) Po: ho) 


{ik, Pk, hk) ,h ) 


and suppose this derivation is typable w.r.t. RT. Then one of 
the following case holds: 

1 ) there exists j,j' with 0 < j < k and 0 < j' < k' s.t. 

ij = i'j and {ij, Pj,hj) ~RTi. ,rt^, {iy, p'y ,h'y) 

^ j' 

2 ) ir,h)-p^p{r',h') 


Proof: We do a case analysis on whether a junction point 
is defined for both of the execution traces. There are 3 possible 
cases : 


1 ) 


2 ) 


3) 


junction point is defined for both of the execution. 
We trace any changed registers during the execu¬ 
tion. If the register is changed, then we can invoke 
Lemma 1.8 to claim that the register is high and 
we know that high register does not affect indistin- 
guishability. If the regi ster is not changed, then we 
can invoke Lemma 


1.9 


to obtain RTi.{r) = RTo{r) 
and p, (r) = po(r)“d p/,(r) = po(r). If RTo{r) 
is low, then we know that po(r) = Po{r), thus we 
can obtain that Pij{r) = piy{r). Otherwise, we know 
that RTi (r) = RTi> (r) is high. Whatever the case 
it does not affect indistinguishability. Since for all 
register in RTi (RTi^ ) they are either changed or 
unchanged, we can obtain {ij,pj,hj) ~RTi.,RT., ,/3 

^ 'j' 

{i'y, p'y,h'y) and we are in Case 1 . 
only one execution has junction point. Eor the part 
where junction point is not defined (assume it is 
the exe cuti on ending in {r,h)), we can invoke 
lemma 1.6 to obtain highResult(r, L). On the 


other execution path, we know from SOAP 5 that 
the junction point is in the region ''oL.i 


1.6 


region(fo,Tg)). Hence we can invoke lemma 
again to obtain highResult(r', L') since se is hipi 
in region(fg, Tg), and prove that we are in Case 2 . 
both of the execution traces have no junction point. In 
this case since we know that se is high in the region, 
we can just invoke lemma |L 6 on both executions to 
obtain highResuIt(r, L) and highResult(r',/i'), 
hence we are in Case 2 . 


Lemma I.ll (High Branching). Let all method m! in P are 
non-interferent w.r.t. all the policies in Policiesr(m')- Let 
m be a method in P, j 3 e L ^ L a partial function, Si,S2 6 
Statec and two registers types rti,rt2 e {TZ S) s.t. 


^1 '^rti ,ri2 ,0 ^2 









1) If there exists two states (ii,Pi,/li), (* 21 P 2 ) ^ 2 ) ® 
Statec and two registers types rtfrt 2 e {'R- S) 

S.t. I- ^2 

(^l5Pl?^l) ^2 ^m,T2 (^ 25 /^ 25 ^ 2 ) 

i rti => rt'-y i r<2 =► rt '2 

then 

se is high in region(i,ri) 
se is high in region(i,T2) 

2) If there exists a state {i[,p[,h[) 6 States, a final 
result {v 2 , h' 2 ) 6 {V + L)x Heap and a registers types 
rt[ € (TZ ^ S) s.t. 

1 ) Pi ^ h'l ) S2 '^m,T2 (r2,/iy 

i rti => rt[ i rt 2 => 

then 

se is high in region(t,ri) 

Proof: By case analysis on the instruction executed. 

• ifeq and ifneq; the proof’s outline follows from 
before as there is no possibility for exception here. 

• invoke : there are several cases to consider for this 
instruction to be a branching instruction; 

1) both are executing normally. Since the method we 
are invoking are non-interferent, and we have that 
Pi ~rti,rt2,/3 P 2 , we will also have indistinguishable 
results. Since they throw no exceptions there is no 
branching there. 

2) one of them is normal, the other throws an excep¬ 
tion e'. Assume that the policy for the method called is 

^ k'h ^ 

k'^ kf This will imply that fc^[e'] ^ fcobs otherwise 
the output will be distinguishable. By the transfer rules 
we have that for all the regions se is to be at least 
as high as k'f[e'^ (normal execution one is lub-ed 
with ke = U{Ar[e] I e 6 excAnalysis(m')} where 
e' 6 excAnalysis(TO'), and fc(.[e'] by itself for the 
exception throwing one), thus we will have se ^ fcobs 
throughout the regions. For the exception throwing 
one, if the exception is caught, then we know we will 
be in the first case. If the exception is uncaught, then 
we are in the second case. 

3) the method throws different exceptions (let’s say 
Cl and 62 ). Assume that the policy for the method 

k'h ^ 

called is ^ kf Again, since the outputs are 
indistinguishable, this means that k'^\ei] ^ fcobs and 
fc(,[e 2 ] ^ fcobs- By the transfer rules, as before we 
will have se high in all the regions required. If the 
exception both are uncaught, then this lemma does 
not apply. Assume that the ei is caught. We follow 
the argument from before that we will have se is 
high in region(i, ti). If e 2 is caught, using the same 
argument we will have se is high in region(i,T 2 ) 
and we are in the first case. If e 2 is uncaught, then 
we know that we are in the second case. The rest of 
the cases will be dealt with by first assuming that e 2 
is caught. 

• object / array manipulation instructions that may throw 
a null pointer exception. This can only be a problem if 


one is null and the other is non-null. From this, we can 
infer that register pointing to object / array reference 
will have high security level (otherwise they have to 
have the same value). If this is the case, then from the 
transfer rules for handling null pointer we have that 
se is high in region region(ii,np). 

Now, regarding the part which is not null, we also can 
deduce that it is from the transfer rules that we have 
se will be high in that region, which implies that se 
will be high in region(i 2 ,Norm) 

• throw. Actually the reasoning for this instruction 
is closely similar to the case of object / array ma¬ 
nipulation instruction that may throw a null pointer 
exception, except with additional possibility of the 
instruction throwing different exception. Fortunately 
for us, this can only be the case if the security level 
to the register pointing to the object to throw is high, 
therefore the previous reasoning follows. 


Lemma 1.12 (Locally Respect (Specialized)). Let all method 
m' in P are non-interferent w.r.t. all the policies in 
Policiesr(TO'). Let m a method in P, e L L a partial 
function, Si, S2 6 State^ two DEXg states at the same program 
point i and two registers types r<i,r <2 e {TZ ^ S) s.t. 

■Si ^2- 

1) If there exists two states s'i,s '2 e States and the 
program point of is the same as s '2 and two 
registers types rtf rt '2 e (TZ ^ S) s.t. 

i rti ft'i i rh 
then there exists fi' e L ^ L s.t. 

Si ~rt'^2 — P 

2) If there exists a state , p'l ,h'f) e States, a final 

result (r2, h' 2 ) 6 {V + L) x Heap and a registers types 

rt'i e (TZ ^ S) s.t. 

'^m,T2 (f2,fcy 

i h-’’! rti rt'i i rt2 => 

then there exists fi' e L ^ L s.t. 

h'i'^pfh' 2 , highResultk,.(r 2 , ^ 2 ) P - P' 

3) If there exists two final results (ri, (r2, ^ 

{V + L) X Heap s.t 

Si {ri,h'i) S2 '^m,T2 {r2,h'2) 

i rti i ^2 => 

then there exists P' e L ^ L s.t. 

{r2,h'2) P £ P' 

Proof: Since we have already proved this lemma for all 
the instructions apart from the exception cases, we only deal 
with the exception here. Moreover, we already proved for the 
heap for instructions without exception to be indistinguishable. 
Therefore, only instructions which may cause an exception are 
considered here, and only consider the case where the registers 
may actually be distinguishable. Note that for exception case. 



the lemma is specialized to only affect those that have the 
same successor’s program point. 

• invoke. There are 6 possible successors here, but we 
only consider the 4 exception related one (since one 
of them can be subsumed by the other) ; 

1) One normal and one has caught exception. 

In this case we know that the lemma is not applicable 
since the successors have different program points. 

2) One normal and one has uncaught exception (the 
case where one throw caught exception and one 
throw uncaught exception is proved using similar 
arguments). In this case, we have one successor 
state while the other will return value or location 
(case 2). So in this case we only need to prove 
that highResultk,.(r 2 ,(the part about heap in- 
distinguishability is already proved). We can easily 
again appeal to the output distinguishability since 
we already assumed that the method m' is non- 
interferent. Since we have the exception e returned 
by the method m' as high (fc'[e]), we can now use 
the transfer rule which states that fc^[e] < kr[e] and 
establish that kr[e] ^ fcobs which in turns implies that 
highResultk,.(r 2 ,thus we are in Case 2. 

3) Both has caught exception If they have the same 
exception, then we that the content of ex register will 
be the same thus the register will be indistinguishable. 
The case where the exceptions are different is not 
covered in this lemma since they will lead to different 
handlers, thus different program point. 

4) Both has uncaught exception (and different excep¬ 
tion on top of that). Let’s say the two exceptions 
are ei and 62 - For the beginning, we use the output 
indistinguishability of the method to establish that 
fcj!,[ei] i kohs and fc'[e 2 ] i kohs- Then, using the 
transfer rules for uncaught exceptions whichs states 
fc(,[ei] < kr\^ei] and < fcr[e 2 ] to establish that 
fcr[ei] and ^^.[ 62 ] are high as well. Now, since they 
are both high, we can claim that they are indistinguish¬ 
able (output-wise), therefore concluding the proof that 
we are in Case 3. 

• iget. There are four cases to consider here: 

1) One is normal execution and one has caught null 
exception. In this case we know that the lemma is not 
applicable since the successors have different program 
points. 

2) One is normal execution and one has uncaught 
null exception. The only difference with the previous 
case is that there will be one execution returning 
a location for exception instead. In this case, we 
only need to prove that this return of value is high 
(highResuItk,.(r 2 ,/ 12 )). We know that Tq (the reg¬ 
ister containing the object) is high (sec{ro) i kohs), 
otherwise si +rti,rt 2/3 52 - The transfer rule for iget 
with uncaught exception states that sec{ro) < fcr[np], 
which will give us A:r.[np] ^ kohs, which will implies 
that highResultk,.(r 2 , 112 ), thus we are in Case 2. 

3) Both has caught null exception. In this case, there 
are two things that needs consideration: the new ob¬ 
jects in the heap, and the pseudo-register ex containing 
the new null exception. Since we have hi /12 


and the exception is created fresh (h = fresh(/ii), 

11 1 -^ def aultn p, h = fresh(/i 2 ), h defaultnp), 

by lemma E.6 we have that h[ as well. Now 

for the pseudo-register ex, we take the mapping /3' 
to be /3 ffi {^1 I 2 }, where li = fresh(ft,i) and 

1 2 = fresh(/i 2 )j both are used to store the new 
exception. Under this mapping, we know that li I 2 
and this will give us pi p '2 since p'l = {ex Zi} 
and p '2 = {ex I 2 }, thus we are in Case 1. 

4) Both has uncaught null exception. Following the 
previous arguments, we have h'l h' 2 , and li I 2 , 
which will give us {{li),h'^) ~pf {{l 2 ),h' 2 ), thus we 
are in Case 3. 


• iput, aget, and aput. The arguments closely follows 
that of iget 

• throw. There are four cases to consider here : 

1) Two same exception. In this case, we know that the 
exception will be the same, therefore the value for ex 
will be the same {ex = pi(re) = P 2 (fe)), thus giving 
us p'l p'2 if the exception is caught (Case 1). In the 
case where the exception is uncaught, we know that 
the value will be the same, that is pi(re), therefore 
the output will be indistinguishable as well (Case 3). 

2) Two different exceptions, both are caught. In this 
case we know that the lemma is not applicable since 
the successors have different handlers (thus program 
points). 

3) Two different exceptions, both are uncaught. The 
transfer rules states that rt'i{re) < kr{ei\ and 
rt'2{re) < kr[e2] (where Ve is the register containing 
the exception). Since must be high to have different 
value, therefore kr{ei] and ^^[ 62 ] must be high as 
well. With this, we will have that (ri, h'l) (r 2 , h'2) 
since both are high outputs (Case 3). 

4) Two different exceptions, one is caught one is 

uncaught. Similar to the previous argument: we know 
that fcr[e] will be high, therefore we will have 
highResultk, ( 7 ’ 2 ,/i^, h'l h'2 (throw instruction 

does not modify the heap), and /3 £ /?' (Case 2). 


Lemma 1.13 (Typable DEX Program is Non-Interferent). 
Suppose we have /? a partial function j3 e C ^ C and 
(*o, PO: ^o); (*o> Po’^0) ^ Statec two DEXg states s.t. ig = i'^ 
and {io,po,ho) -RTi^^RT., ,p {i'^, p'Q,h'f}. Suppose we have a 
derivation 


{io,Po,ho) ■ ■ ■ {ik, Pk, hk) '^m,Tk{r,h) 

and suppose this derivation is typable w.r.t. RT. Suppose we 
also have another derivation 


(*0> Poj ^ 0 ) ■ ■ ■ (*fc> Pki^k) 5 ^ ) 

and suppose this derivation is typable w.r.t. RT. Then what we 
want to prove is that there exsts /3' € C ^ C s.t. 

{r,h) {r',h') and ^0 £/3' 


Proof: Eollowing the proof in the side effect safety, we use 
induction on the length of method call chain. Eor the base case, 
there is no invoke instruction involved (method call chain 



with length 0 ). A note about this setting is that we can use 
lemmas which assume that all the methods are non-interferent 
since we are not going to call another method. To start the 
proof in the base case of induction on method call chain length, 
we use induction on the length of k and k'. The base c ase is 
when fc = fc' = 0 . In this case, we can use case 3 of Lemma [I. 12 | 
There are several possible cases for the induction step: 


1 ) fc > 0 and k' = 0: then we can use case 2 of 
Lemma 1.12 to get existence of P' € C ^ C s.t. 

hi~p'h', highResultk,.(r',/i') and P ^ P' [1] 

Using case 2 of Lemma [ 1. 11 1 we get 

se is high in region(io,ri) 


where ti is the tag s.t. iq U- SOAP 2 gives us 
that eitherii 6 region(io, ti) or ii = jun(io,Ti) but 
the later case is rendered impossible due to SOAP 3 . 
Applying Lemma we get 

highResultk,.(r,and hi~ph[ [2] 


Combining [ 1 ] and [ 2 ] we get 

hi h'l, hi h', (r, h) ~ (r', h') 


2 ) 

3) 


to conclude. 

fc = 0 and k' > 0 is symmetric to the previous case, 
fc > 0 and k' > 0 . If the next instruction is at the 
same program point (ii = i'l) we can conclude using 
the case 1 of Lemma [i.l 2 | and induction hypothesis. 
Otherwise we will have registers typing rti and rt'^ 

io RTig ^ rti, rti E 
i'd h'^o RT^,^ rt[, rt'i E RTi,^ 

Then using case 1 of Lemma |I.l 1 | we have 

se is high in region(io,T) 
se is high in region(iQ, r') 


where r,r' are ta gs s.t . zg zi and Zq i'l. Using 
case 1 of Lemma 1.12 there exists / 3 ', /3 £ / 3 ' s.t. (with 


the help of Lemma F .4 


{ill Pi,hi) ,/ 3 ' {i'liP'iih'i) 

Invoking Lemma [ 1 . 10 | will give us two cases: 

• There exists j,j' with 1 < j < k and 1 < f < 
k' s.t. ij = z', and {ij,pj,hj) '^RTi. ,rt-, ,i3 

^ j 

{i'j, p'j, h'j). We can then use induction hy¬ 
pothesis on the rest of executions to conclude. 

• {r,h) p, {r',h') and we can directly 
conclude. 


After we established the base case, we can then continue 
to prove the induction on method call chain. In the case where 
an instruction calls another method, we will have the method 
non-interferent since they necessarily have shorter call chain 
length (induction hypothesis). 


Proof of Theorem IV. 1 is direct application of Lemma 1.13 
and Lemma |L 4 ] 



















